[Python] basic parallelisatie

[julby]

Ik werk de laatste tijd nogal veel met Python scripts die met name door de grote hoeveelheid te verwerken data (3D arrays) bijzonder traag zijn. Vaak komt dit neer op een opeenvolging van berekeningen die volgens mij prima te paralleliseren zijn (berekeningen onafhankelijk van elkaar). In Python zijn hiervoor een aantal opties beschikbaar (o.a. PP) maar deze gaan volgens mij vrijwel altijd uit van een berekening a die x keer parallel uitgevoerd wordt. Wat ik typisch heb:

code:

..
..
berekening a
..
berekening b
..
berekening a*b

Normaal wordt dit uitevoerd als:

code:

berekening a -> berekening b -> berekening a*b

maar ik zou eigenlijk de berekeningen a en b, beiden op een aparte processor, gelijktijdig willen starten waarna berekening a*b van start mag gaan:

code:

berekening a \
              --> berekening a*b
berekening b /

Iemand enig idee of dit in Python eenvoudig te realiseren is?

Bij voorbaat dank

[Boudewijn]

http://docs.python.org/library/threading.html

Al gezien? Met semaforen kun je dit .

[Aloys]

Nog een simpele optie: maak een script die alle berekeningen A doet en een script die alle berekeningen B doet. Daarna nog een script die alle berekeningen A*B doet. In dit geval zal je OS zelf de load verdelen over de cores . ( Per script max 1 core)

[Boudewijn]

Ja maar dan zit je wel met dat je (a*b) pas kan starten *na* a en *na* b. Er moet dus communciatie zijn.

[ValHallASW]

Boudewijn schreef op dinsdag 26 april 2011 @ 00:12:
http://docs.python.org/library/threading.html

Al gezien? Met semaforen kun je dit .

Ware het niet dat je in Python last hebt van de GIL. Kortweg komt het erop neer dat je geen computational parallelisatie kunt doen omdat python een globale lock heeft. De precieze details zijn niet zo relevant, maar de take-home-message is dat python-threading alleen nuttig is voor IO.

Wat je wél kunt doen is met verschillende processen werken die met elkaar communiceren. Dan maak je een lichtgewicht proces dat puur de berekening doet, die gooi je vervolgens door psyco oid. De communicatie kan je dan bv met pipes uitvoeren - maar ik moet bekennen dat ik geen ervaring heb met cpu-bound parallelisatie in python ;-)

[Verwijderd]

Als het rekenwerk de bottleneck is dan kun je afvragen of Python wel de juiste keuze is. Je zou de code die de number crunching doet ook in bijv. C kunnen schrijven. Daar win je waarschijnlijk meer mee dan het opsplitsen in threads of processen. Python kan relatief eenvoudig met C code interfacen.

Een ander mogelijke optie is om een library te gebruiken zoals SciPy of ScientificPython (voor meer suggesties zie http://wiki.python.org/moin/NumericAndScientific)

[RayNbow]

ValHallASW schreef op dinsdag 26 april 2011 @ 00:20:
[...]

Ware het niet dat je in Python last hebt van de GIL. Kortweg komt het erop neer dat je geen computational parallelisatie kunt doen omdat python een globale lock heeft. De precieze details zijn niet zo relevant, maar de take-home-message is dat python-threading alleen nuttig is voor IO.

Voor wie wel wil weten wat de GIL doet, PyCon 2010:Understanding the Python GIL (#82).

Wat je wél kunt doen is met verschillende processen werken die met elkaar communiceren. Dan maak je een lichtgewicht proces dat puur de berekening doet, die gooi je vervolgens door psyco oid. De communicatie kan je dan bv met pipes uitvoeren - maar ik moet bekennen dat ik geen ervaring heb met cpu-bound parallelisatie in python ;-)

Met de multiprocessing module kun je in Python redelijk gemakkelijk processen forken, maar deze module zit er pas in sinds 2.6. Er is wel een backport beschikbaar voor 2.5.

* RayNbow kwam net deze pagina tegen met andere oplossingen: http://wiki.python.org/moin/ParallelProcessing

[julby]

Dat is nog eens snel antwoord Bedankt! Een paar reacties:

@Aloys: Bedoel je dan dat je de scripts simultaan handmatig start? Want bij een script a en een script b beiden vanuit een script c aanroepen gaat toch nog steeds alles serieel?

@De Zeester: C++ of Fortran was inderdaad een betere keuze geweest, ik had me in eerste instantie niet beseft dat dit zulke rekenintensieve taken zouden worden. Ik gebruik waar mogelijk al SciPy (filter operaties) en/of Numpy bij de bewerking van de arrays.

@RayNBow: Ik gebruik Python 2.7 dus zal eens kijken naar de multiprocessing module

Bedankt allen, zal de aangeboden opties eens bekijken

[Loy]

Misschien is dit ook interessant: http://www.dabeaz.com/generators/.
Toevallig kwam ik dit tegen op reddit:
http://www.reddit.com/r/P..._done_with_python/c1r1bav
Wellicht te combineren tot een aantal processen die een pipeline vormen?

[0fbe]

Leuk dat hierboven de GIL wordt aangehaald, maar dit is alleen van toepassing op CPython, niet op Jython en IronPython. Als je toch CPython gebruikt kan je altijd kijken naar inter-process-communication om taken te voltooien.
Je zou ook bijv. ZeroMQ kunnen gebruiken om tussen processen te communiceren, a en b sturen de resultaten naar a*b welke vervolgens de output berekend...

[ Voor 25% gewijzigd door 0fbe op 26-04-2011 23:11 ]

[julby]

Zo, eerst maar eens een simpel deel uitgetest, een deel wat wel gemakkelijk in x keer dezelfde berekening kon worden opgesplits (met parellel Python). Het resultaat is alleen helaas geen snelheidswinst, ik zie nu dat het script netjes 4 processoren gebruikt, maar in plaats van 1 processor op ~100% gebruikt het script nu 4 processoren op ~25-30%. Ik ben bang dat I/O toch de bottleneck is hier

[Tim]

Als je numpy/scipy gebruikt (lijkt me wel als je bezig bent met vectoren en matrices het vermendigvuldigen van veel 3d arrays), dan is het handig om te weten dat die de GIL vrijgeeft bij de meeste operaties en dus wel baat heeft bij gebruik van de de threading module.

[ Voor 9% gewijzigd door Tim op 27-04-2011 23:25 ]