Billede kilde: Pixabay (Gratis billede)

Leder du efter "GPU-drevet datavidenskab"?

 
 
Forestil dig, at du er dataforsker, forretningsanalytiker eller akademisk forsker i fysik/økonomi/neurovidenskab...

Du gør en masse datastrid, rengøring, statistiske test, visualiseringer regelmæssigt. Du piller også med en masse lineære modeller tilpasse data og indimellem begive sig ud i RandomForest. Du er også til klyngedannelse store datasæt. Lyder det bekendt nok?

Men i betragtning af arten af ​​de datasæt, du arbejder på (for det meste tabelformede og strukturerede), begiver du dig ikke så meget ud i dyb læring. Du vil hellere lægge alle de hardwareressourcer, du har, i de ting, du rent faktisk gør i hverdagen, end at bruge på en eller anden fancy dyb læringsmodel. Igen, bekendt?

Du hører om den fantastiske kraft og den lynhurtige beregningsevne GPU-systemer som dem fra NVidia til alle former for industrielle og videnskabelige applikationer.

Og du bliver ved med at tænke - "Hvad er der for mig? Hvordan kan jeg drage fordel af disse kraftfulde stykker halvleder i min specifikke arbejdsgang? "

Du søger efter GPU-drevet datavidenskab.

En af dine bedste (og hurtigste) muligheder for at evaluere denne tilgang er at bruge kombinationen af Saturn Sky + HURTIGE. Lad mig forklare i detaljer...

GPU'er i AI/ML-folkloren har primært været til dyb læring

 
 
Mens brugen af ​​GPU'er og distribueret computing er meget diskuteret i de akademiske kredse og erhvervslivet til kerne AI/ML-opgaver (f.eks. 1000-lags dybt neuralt netværk til billedklassificering el milliard-parameter BERT talesyntesemodel), har de fundet mindre dækning, når det kommer til deres nytte til almindelige datavidenskabelige og datatekniske opgaver.

Ikke desto mindre, datarelaterede opgaver er den væsentlige forløber for enhver ML-arbejdsbelastning i en AI-pipeline og de udgør ofte en majoritetsprocent af tiden og intellektuel indsats brugt af en dataforsker eller endda en ML-ingeniør. For nylig den berømte AI-pioner
Andrew Ng snakkede om at gå fra en modelcentreret til en datacentreret tilgang til AI værktøjsudvikling. Det betyder, at du skal bruge meget mere tid på de rå data og forbehandle dem, før en faktisk AI-arbejdsbelastning udføres på din pipeline.

Så det vigtige spørgsmål er: Kan vi udnytte kraften ved GPU og distribueret databehandling til almindelige databehandlingsjob?

Billede kilde: Forfatteren har lavet collage fra gratis billeder (Pixabay)

 

Mens brugen af ​​GPU'er og distribueret computing diskuteres bredt i de akademiske kredse og erhvervslivet til kerne AI/ML-opgaver, har de fundet mindre dækning i deres nytte til almindelige datavidenskabelige og dataingeniøropgaver.

Det fantastiske RAPIDS-økosystem

 
 
 RAPIDS suite af softwarebiblioteker og API'er give dig - en almindelig dataforsker (og ikke nødvendigvis en deep learning practitioner) - muligheden og fleksibiliteten til at udføre end-to-end datavidenskab og analysepipelines udelukkende på GPU'er.

Dette open source-projekt blev inkuberet af Nvidia ved at bygge værktøjer til at drage fordel af CUDA-primitiver. Det fokuserer specifikt på eksponerer GPU-parallelisme og hukommelseshastighedsfunktioner med høj båndbredde gennem det datavidenskabsvenlige Python-sprog.

Fælles dataforberedelse og skænderier er højt værdsat i RAPIDS-økosystemet. Det låner også et betydeligt beløb af understøttelse af multi-node, multi-GPU-implementering og distribueret behandling. Hvor det er muligt, integreres det med andre biblioteker, der laver ikke mere hukommelse (dvs. datasætstørrelse større end individuel computer RAM) databehandling nem og tilgængelig for individuelle dataforskere.

Billede kilde: Forfatteren har lavet collage

 

De tre mest fremtrædende (og pytoniske) komponenter - som er af særlig interesse for almindelige dataforskere - er,

• CuPy: Et CUDA-drevet array-bibliotek, der ligner og føles ligesom Numpy, mens du bruger forskellige CUDA-biblioteker, f.eks. cuBLAS, cuDNN, cuRand, cuSolver, cuSPARSE, cuFFT og NCCL for at drage fuld fordel af GPU-arkitekturen nedenunder.
• CuDF: Dette er et GPU DataFrame-bibliotek til indlæsning, aggregering, sammenføjning, filtrering og manipulation af data med en panda-lignende API. Dataingeniører og dataforskere kan bruge det til nemt at accelerere deres opgaveflow ved hjælp af kraftfulde GPU'er uden nogensinde at lære møtrikker og bolte i CUDA-programmering.
• CuML: Dette bibliotek gør det muligt for datavidenskabsfolk, analytikere og forskere at køre traditionelle/klassiske ML-algoritmer og tilknyttede behandlingsopgaver, der fuldt ud udnytter kraften i en GPU. Dette bruges naturligvis mest med datasæt i tabelform. Tænk på Scikit-learn, og hvad det kunne gøre med alle de hundredvis af Cuda- og Tensor-kerner på dit GPU-kort! I de fleste tilfælde matcher cuML's Python API det fra Scikit-learn. Desuden forsøger den at tilbyde understøttelse af multi-GPU og multi-node-GPU by integreres yndefuldt med Dashboard, hvor som helst det kan, for at drage fordel af ægte distribueret behandling/klyngedatabehandling.

Kan vi udnytte kraften ved GPU og distribueret databehandling til almindelige databehandlingsjob og maskinlæring med strukturerede data?

Er det anderledes end at bruge Apache Spark?

 
 
Du kan spørge, hvordan denne GPU-drevne databehandling er anderledes end at bruge Apache Spark. Faktisk er der nogle subtile forskelle, og først for nylig, med Spark 3.0, er GPU'er en almindelig ressource for Spark-arbejdsbelastninger.

Accelererer Apache Spark 3.0 med GPU'er og RAPIDS | NVIDIA-udviklerblog
 

Vi har ikke tid eller plads til at diskutere de unikke forskelle mellem denne GPU-drevne datavidenskabstilgang versus Big Data-opgaver, der er særligt velegnede til Apache Spark. Men stil dig selv disse spørgsmål, og du vil sandsynligvis forstå den subtile forskel,

"Som data scientist, der modellerer økonomiske transaktioner og porteføljestyring, ønsker jeg at løse en lineært ligningssystem med 100,000 variable. Bruger jeg et rent Linear Algebra-bibliotek eller Apache Spark? "

"Som en del af en billedkomprimeringspipeline vil jeg bruge Enkeltværdinedbrydning på en stor matrix af millioner af poster. Er Apache Spark et godt valg til det? "

Stor problemstørrelse betyder ikke altid Apache Spark eller Hadoop økosystem. Big Computation svarer ikke til Big Data. Som en velfunderet dataforsker skal du kende begge dele for at tackle alle slags problemer.

RAPIDS fokuserer specifikt på eksponerer GPU-parallelisme og hukommelseshastighedsfunktioner med høj båndbredde gennem Python API'er.

Hvad viser vi i denne artikel?

 
 

Kun skarpe eksempler på CuPy og CuML

 
Så i denne artikel vil vi blot demonstrere sprøde eksempler på CuPy og CuML,

• hvordan de sammenligner (i hastighed) med tilsvarende Numpy og Scikit-learn funktioner/estimatorer
• hvordan data/problemstørrelsen betyder noget i denne hastighedssammenligning.

CuDF eksempler i en senere artikel

 
Selvom dataingeniøreksempler beslægtet med Pandas databehandling er af stor interesse for mange datavidenskabsmænd, vil vi dække CuDF-eksemplerne i en senere artikel.

Hvad er min GPU-baserede hardwareplatform?

 
Jeg bruger en Saturn Sky Tesla T4 GPU-forekomst, da det bogstaveligt talt er 5 minutters arbejde at spinne op fuldt udstyret og indlæst (med DS- og AI-biblioteker) computerressource i skyen for alt mit datavidenskabelige arbejde med deres service. Så længe jeg ikke overstiger 10 timers Jupyter Notebook-brug om måneden, er det gratis! Hvis du vil læse mere om deres service,

Saturn Cloud Hosted har lanceret: GPU Data Science for Alle!

GPU computing er fremtiden for datavidenskab. Pakker som RAPIDS, TensorFlow og PyTorch muliggør lynhurtigt...

Udover at have Tesla T4 GPU, det er en 4-kernet Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz maskine med 16 GB RAM og 10 GB persistent disk. Så dette er en ganske normal opsætning ud fra et hardwarekonfigurationssynspunkt (begrænset harddisk på grund af det frie niveau), dvs. enhver dataforsker kan have denne slags hardware i sin besiddelse. Den eneste kendetegnende faktor er tilstedeværelsen af ​​GPU'en og opsætning af alle CUDA- og Python-biblioteker på en ordentlig måde, så RAPIDS-pakken fungerer uden problemer.

Stor problemstørrelse betyder ikke altid Apache Spark eller Hadoop økosystem. Big Computation svarer ikke til Big Data. Som en velfunderet dataforsker skal du kende begge dele for at tackle alle slags problemer.

Løsning af et lineært ligningssystem

 
Vi skaber lineære ligningssystemer af varierende størrelse og bruger Numpy (og CuPy) linalg.solverutine for at løse det med følgende kode,

Og koden ændres med et enkelt bogstav (i flere påkaldelser) for CuPy-implementeringen!

Bemærk også, hvordan vi kan oprette CuPy-arrays fra Numpy-arrays som argumenter.

Resultatet er dog dramatisk. CuPy starter langsomt eller i et lignende tempo som Numpy, men slår det lige for store problemstørrelser (antal ligninger).

Enkeltværdinedbrydning

 
Dernæst tackler vi problemet med entalsværdinedbrydning ved hjælp af en tilfældigt genereret kvadratisk matrix (trukket fra en normalfordeling) af varierende størrelser. Vi gentager ikke kodeblokken her, men viser blot resultatet for kortheds skyld.

Det er vigtigt at bemærke, at CuPy-algoritmen ikke viser markant overlegen ydeevne i forhold til Numpy-algoritmen i denne problemklasse. Måske er dette noget, der skal tages op af CuPy-udviklerne for at forbedre.

Tilbage til det grundlæggende: Matrix-inversion

 
Til sidst går vi tilbage til det grundlæggende og overvejer det grundlæggende problem med matrixinversion (brugt i næsten alle maskinlæringsalgoritmer). Resultatet viser igen en stærkt gunstig præstationsforøgelse af CuPy-algoritmen i forhold til Numpy-pakken.

Håndtering af et K-betyder klyngeproblem

 
Dernæst overvejer vi et uovervåget læringsproblem med klyngedannelse ved hjælp af den alt for velkendte k-betydningsalgoritme. Her sammenligner vi en CuML-funktion med en tilsvarende estimator fra Scikit-learn-pakken.

Bare til reference, her er API-sammenligningen mellem disse to estimatorer.

Billede kilde: Scikit-lære , CuML hjemmeside (Open source-projekter)

 

Her er resultatet for et datasæt med 10 funktioner/dimensioner.

Og her er resultatet af et andet eksperiment med et datasæt med 100 funktioner.

Det er klart, at både prøvestørrelsen (antal rækker) og dimensionaliteten (antal kolonner) havde betydning for, hvordan den GPU-baserede acceleration klarede sig overlegent.

Alt for velkendt lineær regressionsproblem

 
Hvem kan ignorere et lineært regressionsproblem til hastighedssammenligning, mens man beskæftiger sig med datasæt i tabelform? Efter kadencen som før varierer vi problemstørrelsen - denne gang både antallet af prøver og dimensioner samtidigt - og sammenligner CuML's ydeevne LinearRegression estimator til den opnået fra Scikit-learn-stalden.

X-aksen i den følgende figur repræsenterer problemets størrelse - fra 1,000 prøver/50 funktioner til 20,000 prøver/1000 funktioner.

Igen yder CuML-estimatoren meget bedre, efterhånden som problemets kompleksitet (prøvestørrelse og dimensionalitet) vokser.

Resumé

 
 
Vi fokuserede på to af de mest fundamentale komponenter i RAPIDS-rammeværket, som har til formål at bringe kraften fra GPU til de daglige opgaver med dataanalyse og maskinlæring, selv når dataforskeren ikke udfører nogen deep learning-opgave.

Billede kilde: Lavet af forfatteren med gratis Pixabay-billeder (Link-1, Link-2, Link-3)

 

Vi brugte en Saturn Sky Tesla T4 baseret instans for nem, gratis og hurtig opsætning og viste nogle få funktioner i CuPy- og CuML-biblioteker og ydeevnesammenligninger af udbredte algoritmer.

• Ikke alle algoritmer fra RAPIDS-bibliotekerne er langt overlegne, men de fleste er det.
• Generelt stiger ydeevnegevinsten hurtigt, efterhånden som problemets kompleksitet (prøvestørrelse og dimensionalitet) vokser
• Hvis du har en GPU, så prøv altid RAPIDS, sammenlign og test, om du opnår nogen ydelse, og gør den til en pålidelig arbejdshest i din datavidenskabspipeline.
• Kodeændringen er minimal, næsten ikke-eksisterende til at skifte over.

Lad kraften fra GPU sætte gang i dit analyse- og datavidenskabelige workflow.

Du kan tjekke forfatterens GitHub repositories for kode, ideer og ressourcer inden for maskinlæring og datavidenskab. Hvis du ligesom jeg brænder for AI/machine learning/datavidenskab, er du velkommen til at gøre det tilføje mig på LinkedIn or Følg mig på Twitter.

Tak til Mel.

 
Original. Genopslået med tilladelse.

Relateret:

• Sådan bruger du NVIDIA GPU Accelerated Libraries
• Hvorfor og hvordan skal du lære "Produktiv datavidenskab"?
• Ikke kun til dyb læring: Hvordan GPU'er accelererer datavidenskab og dataanalyse