Optimaliseringsteknikker for opplæring av CheXNet på Dell C4140 med NVIDIA V100 GPU-er

Artikkelen er skrevet av Rakshith Vasudev og John Lockman – HPC AI Innovation Lab i oktober 2019

Dataforløp er avgjørende for å få mest mulig ytelse fra akseleratorene:

Hva er tf-data, hvorfor bør du arbeide for å bruke dem?

Siden nye dataenheter (for eksempel GPU-er og TPU-er) gjør det mulig å lære opp nevrale nettverk i stadig økende hastighet, er CPU-behandlingen utsatt for å bli flaskehalsen. tf.data-API-en gir brukerne byggeblokker for å utforme inndataforløp som effektivt bruker CPU-en, noe som optimerer hvert trinn i ETL-prosessen.

For å utføre et opplæringstrinn må du først pakke ut og omforme opplæringsdataene og deretter mate dem til en modell som kjører på en akselerator. Men i en napiv synkron implementering, mens CPU-en klargjør dataene, er akseleratoren inaktiv. Derimot, mens akseleratoren lærer modellen, sitter CPU-en inaktiv. Opplæringstrinntiden er dermed summen av både CPU-ens forhåndsbehandlingstid og akseleratoropplæringstiden

Pipelining overlapper preprosesseringen og modellutføringen av et opplæringstrinn. Mens akseleratoren utfører opplæringstrinn N, klargjør CPU-en dataene for trinn N+1. Dette reduserer trinntiden til det maksimale (i motsetning til summen) av opplæringen, og tiden det tar å pakke ut og transformere dataene.

Uten pipelining er CPU-en og GPU/TPU-en inaktiv mye av tiden:

Fig. 1: Sekvensiell utførelse etterlater ofte GPU-en inaktiv

Med pipelining reduseres inaktiv tid betraktelig:

Fig. 2: Pipelining overlapper CPU- og GPU-bruken, noe som maksimerer GPU-bruken

tf.data-API-en gir en pipeliningmekanisme for programvare gjennom tf.data.Dataset.prefetch-transformasjonen, som kan brukes til å koble fra tiden de bruker. Spesielt bruker transformasjonen en bakgrunnstråd og en intern buffer for å forhåndshenting av elementer fra inndatasettet før de blir bedt om det.

Mer informasjon her: https://www.tensorflow.org/guide/performance/datasets

Når man følger retningslinjene som leveres av tensorflow, er det mulig å få en dataforløp som ser slik ut (gammel tilnærming):
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/old_approach.py

I denne tilnærmingen, også kalt den gamle tilnærmingen, gjør tf data pipeline følgende (forutsatt at datasettet for kasse-x-ray er en sekvens av TFRecords):

1. Henter den absolutte listen over filnavn.
2. Bygger et datasett fra listen over filnavn ved hjelp av TFRecordDataset()
3. Opprett et nytt datasett som laster inn og formaterer imager ved å forhåndsprosessere dem.
4. Øsk datasettet.
5. 1000000000000000000000000000
6. Gjenta datasettet.
7. Satsvis datasettet.
8. Forhåndshenting av datasettet for batch_size.

Dette er imidlertid ikke den mest effektive koden. Det fører til stans og hyppige 0 % gpu-bruk. I utgangspunktet bruker den ikke akseleratorene effektivt.

For å konfigurere tf-data pipeline på riktig måte følger vi tilnærmingen som er tatt spesielt av tensorflow-offisielle modeller, den for ResNet.  Forskjellen mellom den gamle tilnærmingen og den nye tilnærmingen er hvordan dataforløp konfigureres før den mates til modellen.

Slik ser den nye tilnærmingen ut:
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/new_approach.py

De offisielle TensorFlow-modellene kalles også en ny tilnærming:

1. Henter den absolutte listen over filnavn.
2. Bygger et datasett fra listen over filnavn ved hjelp av from_tensor_slices()
3. Sharding utføres på forhånd.
4. Datasettet settes opp under opplæringen.
5. Datasettet blir deretter parallelt innfelt, noe som er sammenfelling og behandling av flere filer (definert av cycle_length) for å omforme dem for å opprette TFRecord-datasett.
6. Datasettet blir deretter forhåndsinstallert. Den buffer_size definerer hvor mange poster som er forhåndsstrukket, som vanligvis er mini-batch_size av jobben.
7. Datasettet er koblet til igjen. Detaljer om pste kontrolleres av buffer_size.
8. Datasettet gjentas.  Det gjentar datasettet til num_epochs for å trene.
9. Datasettet utsettes for samtidig map_and_batch() som analyserer tf-postfilene, noe som igjen forhåndsprosesserer imaget og grupperer dem.
10. Det forhåndsprosesserte imaget er klart som et datasett og forhåndsinstallert på nytt.

Her er en sammenligning av ytelsen til både gamle og nye tilnærminger ved bruk av de offisielle TF-modellene.

Fig. 3: Med den nye tilnærmingen kan du forvente nær lineær skalering.

Som det kan ses, er det en betydelig ytelsestap, og det er ingen skalering i det hele tatt med den gamle tilnærmingen. GPU-er vil ofte oppleve lite eller ingen bruk, noe som fører til flat linje for ytelsen. Hvis kommunikasjonen håndteres på en måte, kan du gjøre databehandlingen mer effektiv på flere GPU-er på flere noder, hvis kommunikasjonen håndteres på en god måte.
Hvis CPU-ene gjør det parallelt med forhåndsbehandlingen, er det et annet aspekt å forhåndsbevege de behandlede dataene i minnet og GPU-ene som utfører tunge løft av matrisemultiplikasjon med rask kommunikasjon, noe som gjør denne nye tilnærmingen mer attraktive å skalere for flernoder.

Andre teknikker som skal ses på for å oppnå optimal ytelse:

Det er viktig å ha riktig miljø:

Miljøet som kjører jobbene dine, er like viktig som jobbene dine, ettersom det å ha de riktige bibliotekene/modulene er viktig ettersom de vil påvirke opplæringsytelsen. De nyeste CUDA-relaterte bibliotekene kan også bidra til å forbedre ytelsen.

Følg denne opplæringen for å installere hvis du ikke har et arbeidsmiljøoppsett.

Bruke riktige bindingsparametere for MPI:

MPI er et kommunikasjonsbibliotek som bidrar til horovod for å distribuere jobber. Ulike parameteralternativer for binding og tilordning ble utforsket, og de beste parameterne for C4140 var tilordning etter sokkel. Den anbefalte innstillingen er som følger:
mpirun --map-by socket -np x python pyfile.py --pyoptions

Kontroller at én prosess fungerer på én GPU:

Hvis det er mer enn én prosess som fungerer på én gpu, kan de godt velge gpU-ressurser, forbruke GPU-minne og effektivt ikke tilpasse flere bilder per gruppe, og dermed ansvarlig for å få GPU-ytelsen til å bli rammet. Tensorflow 1.13.1 ble utforsket, men det var som om det hadde en feil på det tidspunktet. Den startet mer enn én prosess per GPU.

Oppsummert:

• Det er viktig å konfigurere data pipeline på riktig måte for å oppnå ytelse.
• Konfigurering av riktig miljø er en god bidragsyter til bedre ytelse.
• Bruk av riktige bindingsparametere for MPI bidrar til å forbedre ytelsen.
• Profiler og løs flaskehalser når GPU-er ikke er fullt ut utnyttet.