6 Python-biblioteker for parallell prosessering

Python har lang tid på bekvemmelighet og programmerervennlighet, men det er ikke det raskeste programmeringsspråket. Noen av hastighetsbegrensningene skyldes at standardimplementeringen, cPython, er en-trådet. Det vil si at cPython ikke bruker mer enn en maskinvaretråd om gangen.

Og mens du kan bruke gjenging modul innebygd i Python for å få fart på ting, gjenging bare gir deg samtidighet, ikke parallellitet. Det er bra for å kjøre flere oppgaver som ikke er CPU-avhengige, men gjør ingenting for å øke hastigheten på flere oppgaver som hver krever en full CPU.

Python inkluderer en innfødt måte å kjøre en Python-arbeidsbelastning på tvers av flere CPUer. De multiprosessering modulen spinner opp flere kopier av Python-tolken, hver på en egen kjerne, og gir primitiver for å dele oppgaver på tvers av kjerner. Men noen ganger til og medmultiprosessering er ikke nok.

Noen ganger krever jobben distribusjon av arbeid ikke bare på tvers flere kjerner, men også på tvers flere maskiner. Det er der disse seks Python-bibliotekene og rammene kommer inn. Alle seks Python-verktøysettene nedenfor lar deg ta et eksisterende Python-program og spre arbeidet over flere kjerner, flere maskiner eller begge deler.

Stråle

Ray er utviklet av et team av forskere ved University of California, Berkeley, og understøtter en rekke distribuerte maskinlæringsbiblioteker. Men Ray er ikke begrenset til maskinlæringsoppgaver alene, selv om det var den opprinnelige brukssaken. Alle Python-oppgaver kan brytes opp og distribueres på tvers av systemer med Ray.

Rays syntaks er minimal, så du trenger ikke å omarbeide eksisterende apper grundig for å parallellisere dem. De @ ray.remote dekorator distribuerer som fungerer på tvers av tilgjengelige noder i en Ray-klynge, med valgfritt angitte parametere for hvor mange CPUer eller GPUer du skal bruke. Resultatene av hver distribuerte funksjon returneres som Python-objekter, slik at de er enkle å administrere og lagre, og mengden kopiering over eller innenfor noder holdes på et minimum. Denne siste funksjonen er nyttig når du for eksempel arbeider med NumPy-matriser.

Ray inkluderer til og med sin egen innebygde cluster manager, som automatisk kan spinne opp noder etter behov på lokal maskinvare eller populære cloud computing-plattformer.

Relatert video: Bruke `multiprosessering` for å få fart på Python

Dask

Fra utsiden ser Dask mye ut som Ray. Det er også et bibliotek for distribuert parallell databehandling i Python, med sitt eget oppgaveplanleggingssystem, bevissthet om Python-datarammer som NumPy, og muligheten til å skalere fra en maskin til mange.

Dask fungerer på to grunnleggende måter. Den første er ved hjelp av parallelliserte datastrukturer - i hovedsak Dask sine egne versjoner av NumPy-arrays, lister eller Pandas DataFrames. Bytt inn Dask-versjonene av disse konstruksjonene for standardinnstillingene, og Dask vil automatisk spre kjøringen over klyngen din. Dette innebærer vanligvis lite mer enn å endre navnet på en import, men kan noen ganger kreve omskriving for å fungere fullstendig.

Den andre måten er gjennom Dask's parallelliseringsmekanismer på lavt nivå, inkludert funksjonsdekoratorer, som pakke ut jobber over noder og returnerer resultater synkront ("umiddelbar" modus) eller asynkront ("lat"). Begge modusene kan også blandes etter behov.

En viktig forskjell mellom Dask og Ray er planleggingsmekanismen. Dask bruker en sentralisert planlegger som håndterer alle oppgaver for en klynge. Ray er desentralisert, noe som betyr at hver maskin kjører sin egen planlegger, så eventuelle problemer med en planlagt oppgave håndteres på nivået til den enkelte maskinen, ikke hele klyngen.

Dask tilbyr også en avansert og fortsatt eksperimentell funksjon kalt "skuespillere". En skuespiller er et objekt som peker på en jobb i en annen Dask-node. På denne måten kan en jobb som krever mye lokal stat kjøre på stedet og kalles eksternt av andre noder, slik at staten for jobben ikke trenger å replikeres. Ray mangler noe som Dasks skuespillermodell for å støtte mer sofistikert jobbfordeling.

Dispy

Dispy lar deg distribuere hele Python-programmer eller bare individuelle funksjoner over en klynge av maskiner for parallell kjøring. Den bruker plattforminnfødte mekanismer for nettverkskommunikasjon for å holde ting raskt og effektivt, slik at Linux-, MacOS- og Windows-maskiner fungerer like bra.

Dispy syntaksen ligner noe multiprosessering ved at du eksplisitt oppretter en klynge (hvor multiprosessering vil du opprette en prosessgruppe), sende arbeid til klyngen og deretter hente resultatene. Det kan være nødvendig med litt mer arbeid for å endre jobber for å jobbe med Dispy, men du får også presis kontroll over hvordan disse jobbene sendes og returneres. For eksempel kan du returnere foreløpige eller delvis fullførte resultater, overføre filer som en del av jobbdistribusjonsprosessen og bruke SSL-kryptering når du overfører data.

Pandaral·lel

Pandaral·lel, som navnet tilsier, er en måte å parallellisere Pandas-jobber på tvers av flere noder. Ulempen er at Pandaral·lel fungerer kun med Pandaer. Men hvis Pandas er det du bruker, og alt du trenger er en måte å akselerere Pandas-jobber over flere kjerner på en datamaskin, er Pandaral·lel laserfokusert på oppgaven.

Merk at mens Pandaral·lel kjører på Windows, vil den bare kjøre fra Python-økter som er lansert i Windows Subsystem for Linux. MacOS og Linux-brukere kan kjøre Pandaral·lel som den er.

Ipyparallel

Ipyparallel er et annet tett fokusert flerbehandlings- og oppgavedistribusjonssystem, spesielt for å parallellisere kjøringen av Jupyter-bærbar kode over en klynge. Prosjekter og team som allerede jobber i Jupyter kan begynne å bruke Ipyparallel umiddelbart.

Ipyparallel støtter mange tilnærminger til parallellisering av kode. På den enkle enden er det kart, som bruker en hvilken som helst funksjon i en sekvens og deler arbeidet jevnt over tilgjengelige noder. For mer komplekst arbeid kan du dekorere bestemte funksjoner for å alltid kjøre eksternt eller parallelt.

Jupyter-notatbøker støtter “magiske kommandoer” for handlinger som bare er mulig i et notatbokmiljø. Ipyparallel legger til noen få magiske kommandoer. For eksempel kan du foran et hvilket som helst Python-utsagn % px for å automatisk parallellisere den.

Joblib

Joblib har to hovedmål: å kjøre jobber parallelt og ikke beregne resultatene hvis ingenting har endret seg. Disse effektivitetene gjør Joblib godt egnet for vitenskapelig databehandling, hvor reproduserbare resultater er hellig. Joblibs dokumentasjon gir mange eksempler på hvordan du bruker alle funksjonene.

Joblib-syntaksen for å parallellisere arbeidet er enkel nok - det utgjør en dekoratør som kan brukes til å dele jobber på tvers av prosessorer, eller til å cache resultater. Parallelle jobber kan bruke tråder eller prosesser.

Joblib inkluderer en gjennomsiktig diskbuffer for Python-objekter opprettet av beregningsjobber. Denne hurtigbufferen hjelper ikke bare Joblib med å unngå gjentatt arbeid, som nevnt ovenfor, men kan også brukes til å stanse og gjenoppta langvarige jobber, eller fortsette der en jobb slapp etter et krasj. Cachen er også intelligent optimalisert for store objekter som NumPy arrays. Regioner med data kan deles i minnet mellom prosesser på samme system ved hjelp av numpy.memmap.

En ting Joblib ikke tilbyr, er en måte å distribuere jobber på flere separate datamaskiner. I teorien er det mulig å bruke Joblibs rørledning til å gjøre dette, men det er sannsynligvis lettere å bruke et annet rammeverk som støtter det naturlig.