6 Python-biblioteker til parallel behandling

Python er længe om bekvemmelighed og programmerervenlighed, men det er ikke det hurtigste programmeringssprog omkring. Nogle af dens hastighedsbegrænsninger skyldes, at dens standardimplementering, cPython, er single-threaded. Det vil sige, cPython bruger ikke mere end en hardwaretråd ad gangen.

Og mens du kan bruge trådning modul indbygget i Python for at fremskynde tingene, trådning kun giver dig samtidighed, ikke parallelisme. Det er godt til at køre flere opgaver, der ikke er CPU-afhængige, men gør intet for at fremskynde flere opgaver, som hver kræver en fuld CPU.

Python inkluderer en indfødt måde at køre en Python-arbejdsbelastning på tværs af flere CPU'er. Det multiprocessing modul spinder op flere kopier af Python-tolken, hver på en separat kerne, og giver primitiver til opdeling af opgaver på tværs af kerner. Men nogle gange enddamultiprocessing er ikke nok.

Nogle gange kræver jobbet distribution af arbejde ikke kun på tværs flere kerner, men også på tværs flere maskiner. Det er her disse seks Python-biblioteker og -rammer kommer ind. Alle seks af Python-værktøjssættene nedenfor giver dig mulighed for at tage en eksisterende Python-applikation og sprede arbejdet over flere kerner, flere maskiner eller begge dele.

Ray

Udviklet af et team af forskere ved University of California, Berkeley, understøtter Ray en række distribuerede maskinlæringsbiblioteker. Men Ray er ikke begrænset til maskinlæringsopgaver alene, selvom det var dets oprindelige brugssag. Alle Python-opgaver kan opdeles og distribueres på tværs af systemer med Ray.

Rays syntaks er minimal, så du behøver ikke omarbejde eksisterende apps grundigt for at parallelisere dem. Det @ ray.remote dekoratør distribuerer den funktion på alle tilgængelige noder i en Ray-klynge med valgfrit specificerede parametre for hvor mange CPU'er eller GPU'er der skal bruges. Resultaterne af hver distribuerede funktion returneres som Python-objekter, så de er nemme at administrere og gemme, og mængden af kopiering på tværs af eller inden for noder holdes på et minimum. Denne sidste funktion er f.eks. Praktisk, når du har at gøre med NumPy-arrays.

Ray inkluderer endda sin egen indbyggede klyngemanager, som automatisk kan rotere noder efter behov på lokal hardware eller populære cloud computing-platforme.

Relateret video: Brug `multiprocessing` for at fremskynde Python

Dask

Udefra ser Dask meget ud som Ray. Det er også et bibliotek til distribueret parallel computing i Python med sit eget opgaveplanlægningssystem, bevidsthed om Python-datarammer som NumPy og evnen til at skalere fra en maskine til mange.

Dask fungerer på to grundlæggende måder. Den første er ved hjælp af paralleliserede datastrukturer - i det væsentlige Dask's egne versioner af NumPy-arrays, lister eller Pandas DataFrames. Udskift Dask-versionerne af disse konstruktioner for deres standardindstillinger, og Dask spreder automatisk deres udførelse over din klynge. Dette involverer typisk lidt mere end at ændre navnet på en import, men kan undertiden kræve omskrivning for at fungere fuldstændigt.

Den anden vej er gennem Dask's paralleliseringsmekanismer på lavt niveau, herunder funktionsdekoratorer, der uddeler job på tværs af noder og returnerer resultater synkront ("øjeblikkelig" tilstand) eller asynkront ("doven"). Begge tilstande kan også blandes efter behov.

En vigtig forskel mellem Dask og Ray er planlægningsmekanismen. Dask bruger en central planlægning, der håndterer alle opgaver til en klynge. Ray er decentraliseret, hvilket betyder, at hver maskine kører sin egen planlægning, så eventuelle problemer med en planlagt opgave håndteres på niveauet for den enkelte maskine, ikke hele klyngen.

Dask tilbyder også en avanceret og stadig eksperimentel funktion kaldet "skuespillere". En skuespiller er et objekt, der peger på et job på en anden Dask-node. På denne måde kan et job, der kræver en masse lokale stater, køre på stedet og kaldes eksternt af andre noder, så tilstanden for jobbet behøver ikke at replikeres. Ray mangler noget som Dask's skuespillermodel for at understøtte mere sofistikeret jobfordeling.

Dispy

Dispy giver dig mulighed for at distribuere hele Python-programmer eller bare individuelle funktioner på tværs af en klynge af maskiner til parallel udførelse. Det bruger platform-native mekanismer til netværkskommunikation for at holde tingene hurtige og effektive, så Linux-, MacOS- og Windows-maskiner fungerer lige så godt.

Dispy syntaks ligner noget multiprocessing ved at du eksplicit opretter en klynge (hvor multiprocessing skulle du oprette en procespulje), indsende arbejde til klyngen og derefter hente resultaterne. Der kan kræves lidt mere arbejde for at ændre job til at arbejde med Dispy, men du får også nøjagtig kontrol over, hvordan disse job sendes og returneres. For eksempel kan du returnere foreløbige eller delvist gennemførte resultater, overføre filer som en del af jobfordelingsprocessen og bruge SSL-kryptering, når du overfører data.

Pandaral·lel

Pandaral·lel, som navnet antyder, er en måde at parallelisere Pandas-job på tværs af flere noder. Ulempen er, at Pandaral·lel fungerer kun med pandaer. Men hvis Pandas er det, du bruger, og alt hvad du behøver, er en måde at fremskynde Pandas-job på tværs af flere kerner på en enkelt computer, er Pandaral·lel laserfokuseret på opgaven.

Bemærk, at mens Pandaral·lel kører på Windows, vil den kun køre fra Python-sessioner, der er lanceret i Windows Subsystem til Linux. MacOS- og Linux-brugere kan køre Pandaral·lel som den er.

Ipyparallel

Ipyparallel er et andet tæt fokuseret multiprocessing- og opgavefordelingssystem, specielt til parallelisering af udførelsen af Jupyter-notebook-kode på tværs af en klynge. Projekter og teams, der allerede arbejder i Jupyter, kan begynde at bruge Ipyparallel med det samme.

Ipyparallel understøtter mange tilgange til parallelisering af kode. I den enkle ende er der kort, der anvender enhver funktion til en sekvens og opdeler arbejdet jævnt på tværs af tilgængelige noder. For mere komplekst arbejde kan du dekorere specifikke funktioner, så de altid kører eksternt eller parallelt.

Jupyter-notesbøger understøtter "magiske kommandoer" til handlinger, der kun er mulige i et notebook-miljø. Ipyparallel tilføjer et par egne magiske kommandoer. For eksempel kan du prefikse enhver Python-sætning med % px for automatisk at parallelisere det.

Joblib

Joblib har to hovedmål: Kør job parallelt og genberegn ikke resultater, hvis intet har ændret sig. Disse effektiviteter gør Joblib velegnet til videnskabelig computing, hvor reproducerbare resultater er hellig. Joblibs dokumentation giver masser af eksempler på, hvordan man bruger alle dens funktioner.

Joblib-syntaks til parallelisering af arbejde er enkel nok - det svarer til en dekoratør, der kan bruges til at opdele job på tværs af processorer eller til at cache resultater. Parallelle job kan bruge tråde eller processer.

Joblib inkluderer en gennemsigtig diskcache til Python-objekter oprettet af beregningsjob. Denne cache hjælper ikke kun Joblib med at undgå gentagelse af arbejde, som nævnt ovenfor, men kan også bruges til at suspendere og genoptage langvarige job eller fortsætte, hvor et job blev stoppet efter et nedbrud. Cachen er også intelligent optimeret til store objekter som NumPy-arrays. Regioner af data kan deles i hukommelsen mellem processer på det samme system ved hjælp af numpy.memmap.

En ting, Joblib ikke tilbyder, er en måde at distribuere job på flere separate computere. I teorien er det muligt at bruge Joblibs pipeline til at gøre dette, men det er sandsynligvis lettere at bruge en anden ramme, der understøtter den indbygget.