Bildekilde: Pixabay (Gratis bilde)

Leter du etter "GPU-drevet datavitenskap"?

 
 
Tenk deg at du er en datavitenskapsmann, eller en forretningsanalytiker, eller en akademisk forsker innen fysikk/økonomi/nevrovitenskap ...

Du gjør mye datakamp, ​​rengjøring, statistiske tester, visualiseringer på en jevnlig basis. Du tukler også med mye lineære modeller passende data og av og til våge deg inn RandomForest. Du er også interessert i det gruppering store datasett. Høres kjent nok ut?

Gitt naturen til datasettene du jobber med (for det meste tabellformet og strukturert), våger du ikke å dype læring så mye. Du vil heller legge alle maskinvareressursene du har i tingene du faktisk gjør på daglig basis, enn å bruke på en fancy dyp læringsmodell. Igjen, kjent?

Du hører om den fantastiske kraften og den lynraske beregningsevnen GPU -systemer som de fra NVidia for alle slags industrielle og vitenskapelige applikasjoner.

Og du fortsetter å tenke - "Hva er det for meg? Hvordan kan jeg dra fordel av disse kraftige delene av halvleder i min spesifikke arbeidsflyt? "

Du søker etter GPU-drevet datavitenskap.

Et av dine beste (og raskeste) alternativer for å evaluere denne tilnærmingen er å bruke kombinasjonen av Saturn sky + RAPIDS. La meg forklare i detalj ...

GPUer i AI/ML -folklore har først og fremst vært for dyp læring

 
 
Mens bruk av GPUer og distribuert databehandling er mye diskutert i akademiske og forretningsmessige kretser for kjerne AI/ML -oppgaver (f.eks. 1000-lags dype nevrale nettverk for bildeklassifisering eller milliard-parameter BERT talesyntesemodell), har de funnet mindre dekning når det gjelder verktøyet deres for vanlige datavitenskap og datatekniske oppgaver.

likevel, datarelaterte oppgaver er den viktigste forløperen for enhver ML-arbeidsmengde i en AI-rørledning og de utgjør ofte en majoritetsprosent av tiden og intellektuell innsats brukt av en datavitenskapsmann eller til og med en ML -ingeniør. Nylig den berømte AI -pioneren
Andrew Ng snakket om flytte fra en modell-sentrisk til en datasentrisk tilnærming til AI utvikling av verktøy. Dette betyr at du bruker mye mer tid på rådata og forarbeider dem før en faktisk AI -arbeidsmengde utføres på rørledningen din.

Så det viktige spørsmålet er: Kan vi utnytte kraften i GPU og distribuert databehandling for vanlige databehandlingsjobber?

Bildekilde: Forfatter opprettet collage fra gratis bilder (Pixabay)

 

Selv om bruk av GPUer og distribuert databehandling er mye diskutert i akademiske og forretningsmessige kretser for kjerne -AI/ML -oppgaver, har de funnet mindre dekning i verktøyet for vanlige datavitenskap og datatekniske oppgaver.

Det fantastiske RAPIDS -økosystemet

 
 
De RAPIDS -pakken med programvarebiblioteker og API -er gi deg - en vanlig datavitenskapsmann (og ikke nødvendigvis en dypt lærende utøver) - muligheten og fleksibiliteten til å utføre ende-til-ende datavitenskap og analyserørledninger helt på GPUer.

Dette open source-prosjektet ble inkubert av Nvidia ved å bygge verktøy for å dra fordel av CUDA-primitiver. Det fokuserer spesielt på avsløre GPU-parallellitet og funksjoner med høy båndbreddehastighet gjennom det datavitenskapelige Python-språket.

Vanlige oppgaver om forberedelse av data og krangling er høyt verdsatt i RAPIDS -økosystemet. Det låner også ut en betydelig mengde støtte for multi-node, multi-GPU distribusjon og distribuert behandling. Når det er mulig, integreres det med andre biblioteker som lager tomt for minne (dvs. datasettstørrelse større enn individuell datamaskin -RAM) databehandling enkel og tilgjengelig for individuelle datavitenskapere.

Bildekilde: Forfatter opprettet collage

 

De tre mest fremtredende (og pytoniske) komponentene - som er av spesiell interesse for vanlige datavitenskapsmenn - er,

• cupy: Et CUDA-drevet matrisebibliotek som ser ut og føles akkurat som Numpy, mens du bruker forskjellige CUDA-biblioteker, f.eks. CuBLAS, cuDNN, cuRand, cuSolver, cuSPARSE, cuFFT og NCCL for å dra full nytte av GPU-arkitekturen under.
• CuDF: Dette er et GPU DataFrame -bibliotek for lasting, aggregering, sammenføyning, filtrering og manipulering av data med en pandas-lignende API. Dataingeniører og datavitenskapere kan enkelt bruke den til å akselerere oppgavestrømmene sine ved hjelp av kraftige GPU -er uten å måtte lære om CUDA -programmering.
• CuML: Dette biblioteket gjør det mulig for datavitenskapsmenn, analytikere og forskere å kjøre tradisjonelle/ klassiske ML -algoritmer og tilhørende behandlingsoppgaver som fullt ut utnytter kraften i en GPU. Naturligvis brukes dette mest med tabellformede datasett. Tenk på Scikit-learn og hva det kan gjøre med alle de hundrevis av Cuda- og Tensor-kjerner på GPU-kortet ditt! På grunn av det stemmer cuMLs Python API i de fleste tilfeller med Scikit-learn. Videre prøver den å tilby støtte for multi-GPU og multi-node-GPU by integrerer grasiøst med CBE, uansett hvor det kan, for å dra nytte av ekte distribuert prosessering/ klynge -databehandling.

Kan vi utnytte kraften i GPU og distribuert databehandling for vanlige databehandlingsjobber og maskinlæring med strukturerte data?

Er det annerledes enn å bruke Apache Spark?

 
 
Du kan spørre hvordan denne GPU-drevne databehandlingen er annerledes enn å bruke Apache Spark. Egentlig er det noen subtile forskjeller, og bare nylig, med Spark 3.0, er GPUer en vanlig ressurs for Spark -arbeidsmengder.

Akselerere Apache Spark 3.0 med GPUer og RAPIDS | NVIDIA utviklerblogg
 

Vi har ikke tid eller plass til å diskutere de unike forskjellene mellom denne GPU-drevne datavitenskapstilnærmingen vs. Big Data-oppgaver som er spesielt egnet for Apache Spark. Men spør deg selv disse spørsmålene, og du vil sannsynligvis forstå den subtile forskjellen,

"Som datavitenskapsmann som modellerer økonomiske transaksjoner og porteføljestyring, vil jeg løse a lineære ligningssystem med 100,000 variabler. Bruker jeg et rent lineært algebra -bibliotek eller Apache Spark? "

"Som en del av en bildekomprimeringsrørledning, vil jeg bruke Enkeltverdidekomponering på en stor matrise med millioner av oppføringer. Er Apache Spark et godt valg for det? "

Stor problemstørrelse betyr ikke alltid Apache Spark eller Hadoop økosystem. Big Computation tilsvarer ikke Big Data. Som en godt avrundet datavitenskapsmann må du vite begge deler for å takle alle slags problemer.

RAPIDS fokuserer spesielt på avslører GPU-parallellitet og funksjoner med høy båndbreddehastighetshastighet gjennom Python APIer.

Hva viser vi i denne artikkelen?

 
 

Skarpe eksempler på CuPy og CuML bare

 
Så i denne artikkelen vil vi bare demonstrere skarpe eksempler på CuPy og CuML,

• hvordan de sammenligner (i hastighet) med tilsvarende Numpy og Scikit-learn-funksjoner/ estimatorer
• hvordan data/problemstørrelse er viktig i denne hastighetssammenligningen.

CuDF -eksempler i en senere artikkel

 
Selv om datatekniske eksempler som ligner på Pandas databehandling er av stor interesse for mange dataforskere, vil vi dekke CuDF -eksemplene i en senere artikkel.

Hva er min GPU-baserte maskinvareplattform?

 
Jeg bruker en Saturn sky Tesla T4 GPU -forekomst, ettersom det bokstavelig talt er 5 minutters arbeid med å spinne opp en fullt utstyrt og lastet (med DS- og AI -biblioteker) beregningsressurser på skyen for alt mitt datavitenskap jobber med deres tjeneste. Så lenge jeg ikke overskrider 10 timer med Jupyter Notebook -bruk per måned, er det gratis! Hvis du vil lese mer om tjenesten deres,

Saturn Cloud Hosted har lansert: GPU -datavitenskap for alle!

GPU -databehandling er fremtiden for datavitenskap. Pakker som RAPIDS, TensorFlow og PyTorch muliggjør lynrask ...

Bortsett fra å ha Tesla T4 GPU, det er en 4-kjerners Intel (R) Xeon (R) Platinum 8259CL CPU @ 2.50 GHz-maskin med 16 GB RAM og 10 GB harddisk. Så dette er et ganske normalt oppsett fra en maskinvarekonfigurasjonssynpunkt (begrenset harddisk på grunn av ledige lag) dvs. enhver datavitenskapsmann kan ha denne typen maskinvare i sin besittelse. Den eneste kjennetegnfaktoren er tilstedeværelsen av GPU og konfigurering av alle CUDA- og Python -bibliotekene på en skikkelig måte, slik at RAPIDS -pakken fungerer uten hikke.

Stor problemstørrelse betyr ikke alltid Apache Spark eller Hadoop økosystem. Big Computation tilsvarer ikke Big Data. Som en godt avrundet datavitenskapsmann må du vite begge deler for å takle alle slags problemer.

Løse et lineært ligningssystem

 
Vi lager lineære ligningssystemer av forskjellige størrelser og bruker Numpy (og CuPy) linalg.solverutine for å løse det med følgende kode,

Og koden endres med en enkelt bokstav (i flere påkallelser) for CuPy -implementeringen!

Vær også oppmerksom på hvordan vi kan lage CuPy -arrayer fra Numpy -arrays som argumenter.

Resultatet er imidlertid dramatisk. CuPy starter sakte eller i samme tempo som Numpy, men slår den helt for store problemstørrelser (antall ligninger).

Singular value dekomposition

 
Deretter tar vi tak i problemet med enkeltverdi -dekomponering ved hjelp av en tilfeldig generert firkantmatrise (trukket fra en normalfordeling) av varierende størrelser. Vi gjentar ikke kodeblokken her, men viser bare resultatet for korthet.

Betydelig å merke seg at CuPy -algoritmen ikke viser markant bedre ytelse enn Numpy -algoritmen i denne problemklassen. Kanskje er dette noe som skal tas opp av CuPy -utviklerne for å forbedre.

Å gå tilbake til det grunnleggende: Matriseinversjon

 
Til slutt går vi tilbake til det grunnleggende og vurderer det grunnleggende problemet med matriseinversjon (brukt i nesten alle maskinlæringsalgoritmer). Resultatet viser igjen sterkt gunstig ytelsesøkning med CuPy -algoritmen over den fra Numpy -pakken.

Å takle et K-betyr klyngeproblem

 
Deretter vurderer vi et uovervåket læringsproblem med gruppering ved hjelp av den altfor kjente k-middelalgoritmen. Her sammenligner vi en CuML-funksjon med en ekvivalent estimator fra Scikit-learn-pakken.

Bare for referanse, her er API -sammenligningen mellom disse to estimatorene.

Bildekilde: Scikit lære og CuML nettsted (Open-source prosjekter)

 

Her er resultatet for et datasett med 10 funksjoner/dimensjoner.

Og her er resultatet av et nytt eksperiment med et datasett med 100 funksjoner.

Det var tydelig at både prøvestørrelsen (antall rader) og dimensjonalitet (antall kolonner) hadde betydning for hvordan den GPU-baserte akselerasjonen var overlegen.

Altfor kjent lineær regresjonsproblem

 
Hvem kan ignorere et lineært regresjonsproblem for hastighetssammenligning mens du arbeider med tabelldatasett? Etter kadensen som før, varierer vi problemstørrelsen - denne gangen både antall prøver og dimensjoner samtidig - og sammenligner ytelsen til CuML LinearRegression estimator til det som er hentet fra Scikit-learn-stallen.

X-aksen i figuren nedenfor representerer problemstørrelsen-fra 1,000 prøver/50 funksjoner til 20,000 prøver/1000 funksjoner.

Igjen fungerer CuML -estimatoren mye bedre etter hvert som problemkompleksiteten (utvalgsstørrelse og dimensjonalitet) vokser.

Oppsummering

 
 
Vi fokuserte på to av de mest grunnleggende komponentene i RAPIDS -rammeverket, som tar sikte på å bringe kraften i GPU til de daglige oppgavene til dataanalyse og maskinlæring, selv når datavitenskapsmannen ikke utfører noen dype læringsoppgaver.

Bildekilde: Laget av forfatteren med gratis Pixabay -bilder (Link-1, Link-2, Link-3)

 

Vi brukte en Saturn sky Tesla T4 -basert forekomst for enkelt, gratis og raskt oppsett og viste noen få funksjoner i CuPy- og CuML -biblioteker og ytelses sammenligninger av mye brukte algoritmer.

• Ikke alle algoritmer fra RAPIDS -bibliotekene er langt bedre, men de fleste er det.
• Generelt øker ytelsesgevinsten raskt etter hvert som problemkompleksiteten (utvalgsstørrelse og dimensjonalitet) vokser
• Hvis du har en GPU, må du alltid prøve RAPIDS, sammenligne og teste om du oppnår ytelse, og gjør den til en pålitelig arbeidshest i datavitenskapens pipeline.
• Kodeendringen er minimal, nesten ikke-eksisterende for å bytte.

La kraften i GPUen sette i gang arbeidsflyten for analyse- og datavitenskap.

Du kan sjekke forfatterens GitHub repositories for kode, ideer og ressurser innen maskinlæring og datavitenskap. Hvis du, som meg, brenner for AI / maskinlæring / datavitenskap, må du gjerne gjøre det legg meg på LinkedIn or Følg meg på Twitter.

Takk til Mel.

 
original. Ompostet med tillatelse.

Relatert:

• Hvordan bruke NVIDIA GPU-akselererte biblioteker
• Hvorfor og hvordan skal du lære "Produktiv datavitenskap"?
• Ikke bare for dyp læring: Hvordan GPUer akselererer datavitenskap og dataanalyse