Optimeringstekniker för finjustering av CheXNet på Dell C4140 med Nvidia V100-grafikprocessorer

Artikeln skrevs av Rakshith Vasudev och John Lockman på HPC AI Innovation Lab i oktober 2019

Datapipeline är avgörande för att få ut så mycket som möjligt av förstärkare:

Vad är tf data, varför ska du sträva efter att använda dem?

Eftersom nya datorenheter (t.ex. grafikprocessorer och TPU:er) gör det möjligt att träna neurala nätverk med en allt snabbare hastighet tenderar processorbearbetningen att bli flaskhals. tf.data API ger användarna byggstenar för att utforma inmatningsflöden som effektivt använder processorn och optimerar varje steg i ETL-processen.

För att utföra ett utbildningssteg måste du först extrahera och omvandla utbildningsdata och sedan skicka dem till en modell som körs på en accelerator. Men i en nandetve-synkron implementering är acceleratorn i viloläge medan processorn förbereder data. Omvänt gäller att processorn är i viloläge medan acceleratorn finjusterar modellen. Utbildningsstegstiden är alltså summan av både processorförbearbetningstiden och acceleratorutbildningstiden

Pipelining överlappar förprocessing och modellkörning av ett utbildningssteg. Medan acceleratorn utför utbildningssteg N förbereder processorn data för steg N+1. På så sätt minskar du stegtiden till den maximala (till skillnad från summan) av utbildningen och den tid det tar att extrahera och omvandla data.

Utan pipelining är processorn och GPU:n/TPU:n inaktiva en stor del av tiden:

Bild 1: Sekventiell körning gör ofta att GPU:n blir inaktiv

Med pipelining minskar den inaktiva tiden avsevärt:

Bild 2: Pipelining överlappar processor- och GPU-användning och maximerar GPU-användning

tf.data API tillhandahåller en mekanism för programvaruanalys via tf.data.Dataset.prefetch-övergång, som kan användas för att frikoppla tidsdata från den tidpunkt då de förbrukas. I övergången används en bakgrundstråd och en intern buffert för förhämtning av element från indatauppsättningen innan de begärs.

Mer information finns här: https://www.tensorflow.org/guide/performance/datasets

När man följer riktlinjerna från Tensorflow är det möjligt att få en datapipeline som ser ut så här (gammal metod):
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/old_approach.py

I det här tillvägagångssättet, som även kallas det gamla tillvägagångssättet, gör tf data pipeline följande (förutsatt att den uttända x ray-datauppsättningen är en sekvens av TFRecords):

1. Hämtar den absoluta listan med filnamn.
2. Skapar en datauppsättning från listan med filnamn med TFRecordDataset()
3. Skapa en ny datauppsättning som läser in och formaterar avbildningar genom att förbehandla dem.
4. Shard datauppsättningen.
5. Koppla ihop datauppsättningen under inlärningen.
6. Upprepa datauppsättningen.
7. Batcha datauppsättningen.
8. Ta bort datauppsättningen för batch_size.

Det här är dock inte den kod som fungerar mest. Det orsakar fördröjningar och 0 % gpu-användning ofta. I grunden använder den inte acceleratorerna på ett effektivt sätt.

För att korrekt konfigurera tf data pipeline följer vi den metod som tensorflows officiella modeller har vidtagit, särskilt den för ResNet.  Skillnaden mellan den gamla metoden och den nya metoden är hur data pipelinen konfigureras innan den matas in på modellen.

Så här ser det nya tillvägagångssättet ut:
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/new_approach.py

TensorFlows officiella modellutformning kallas även för en ny metod:

1. Hämtar den absoluta listan med filnamn.
2. Bygger en datauppsättning från listan med filnamn med hjälp av from_tensor_slices()
3. Sharding görs i förväg.
4. Datauppsättningen flyttas under inlärningen.
5. Datauppsättningen är sedan parallellt interfolierad, vilket är interfoliering och bearbetning av flera filer (definieras av cycle_length) för att omvandla dem för att skapa TFRecord-datauppsättning.
6. Datauppsättningen har sedan förhämtning. Buffer_size definierar hur många poster som är förhämtningsbara, vilket vanligtvis är jobbets mini-batch_size.
7. Datauppsättningen flyttas igen. Detaljer om utväxlingen kontrolleras av buffer_size.
8. Datauppsättningen upprepas.  Datauppsättningen upprepas tills den num_epochs att träna.
9. Datauppsättningen utsätts för samtidiga map_and_batch() som tolkar tf-postfilerna, vilket i sin tur förbehandlar avbildningen och batchar dem.
10. Den förbearbetade avbildningen är klar som en datauppsättning och förhämtning igen.

Här är en jämförelse av prestandan hos både gamla och nya metoder, med hjälp av TF:s officiella modeller.

Bild 3: Med den nya metoden kan det vara nära linjär skalning.

Som det kan ses finns det ett betydande prestandaproblem och det finns ingen skalning alls med det gamla tillvägagångssättet. GPU:er skulle ofta uppleva liten eller ingen användning, vilket gör att prestandan planas ut. Att effektivisera beräkning på en grafikprocessor innebär att beräkning blir mer effektiv på flera grafikprocessorer på flera noder om kommunikationen hanteras korrekt.
Att ha processorer utför förbearbetning parallellt, och förhämtning av bearbetade data i minnet och grafikprocessorer som utför det tunga lyftet av matris multiplikering med snabb kommunikation är en annan aspekt som gör detta nya synsätt mer intressant att skala för multinoder.

Andra tekniker att titta på för att uppnå optimal prestanda:

Det är viktigt att ha rätt miljö:

Miljön som kör dina jobb är lika viktig som dina jobb, eftersom det är viktigt att ha rätt bibliotek/moduler, eftersom de påverkar utbildningsprestandan. Att även ha de senaste CUDA-relaterade biblioteken kan bidra till bättre prestanda.

Följ den här självstudiekursen för att installera om du inte har en arbetsmiljö.

Använda korrekta bindningsparametrar för MPI:

MPI är ett kommunikationsbibliotek som skapar horovod för att distribuera jobb. Olika bindnings- och mappningsparameteralternativ utforskades och de bästa parametrarna för C4140 mappades efter sockel. Den rekommenderade inställningen är som följer:
mpirun --map-by socket -np x python pyfile.py --pyoptions

Se till att en process fungerar på en grafikprocessor:

Om det finns mer än en process som fungerar med en grafikprocessor kan de mycket väl vara till nytta för GPU-resurser, konsumera GPU-minne och i själva verket inte montera fler bilder per batch, vilket innebär att det är ansvarigt för att GPU-prestandan ska påverkas. Tensorflow 1.13.1 utforskades, men det verkar som om det hade en bugg vid den tidpunkten. Fler än en process per grafikprocessor startades.

Sammanfattning:

• Korrekt konfiguration av datapipeline är mycket viktigt för att prestandan ska gå bra.
• Att ställa in rätt miljö är en bra bidragande faktor till bättre prestanda.
• Genom att använda korrekta bindningsparametrar för MPI kan du förbättra prestandan.
• Profilera och åtgärda flaskhalsar när grafikprocessorerna inte används fullt ut.