PyPy mit Anaconda?

mit matplotlib, NumPy, pandas, SciPy, SymPy und weiteren mathematischen Programmbibliotheken.
consuli
User
Beiträge: 31
Registriert: Sonntag 26. Juli 2015, 22:10

PyPy mit Anaconda?

Beitragvon consuli » Mittwoch 30. November 2016, 20:32

Hallo,

in einem anderen Forum wurde mir der alternative PyPy Interpreter/ Compiler für GIL freies paralleles Programmieren empfohlen.

Wie kann ich PyPy im Zusammenspiel mit Anaconda distro installieren?

Gruss und Dank
Consuli
Benutzeravatar
BlackJack
Moderator
Beiträge: 32769
Registriert: Dienstag 25. Januar 2005, 23:29
Wohnort: Berlin
Kontaktdaten:

Re: PyPy mit Anaconda?

Beitragvon BlackJack » Mittwoch 30. November 2016, 21:04

@consuli: Für das was Du willst vergiss Python einfach. Andererseits wird Python mit GIL für das was machen willst, ja bereits verwendet. Also ist die Frage was Du nun genau gegen `multiprocessing` hast, oder wo dich das GIL konkret behindert.

Du willst ja sicher nicht nur ”reines” Python verwenden, sondern die üblichen Bibliotheken die man bei wissenschaftlichen Rechnen so verwendet, also Numpy, Scipy, Matplotlib, Pandas, … — die werden aber nicht mit PyPy laufen. An Numpy wird zwar gearbeitet, aber warten möchte man da vielleicht nicht drauf wenn man *jetzt* Code schreiben will/muss.

Ich sehe auch nicht unbedingt das, wie von Dir behauptet, viele auf eine andere GIL-freie Python-Implementierung umsteigen. Könnte man zum Beispiel mit Jython ja jetzt schon haben. Aber ich sehe auch noch nicht das Python 2.7 in absehbarer Zukunft nicht mehr verwendet wird, oder das ich davon so schnell weg kommen werde. Wenn das mit Python 3.x so weiter geht das Python 4 den scherzhaften Codenamen „Java“ bekommt, muss ich mich vielleicht sowieso nach einer anderen Sprache umschauen. :twisted:
“XML combines all the inefficiency of text-based formats with most of the unreadability of binary formats :-)” — Oren Tirosh, c.l.p, 2002
DasIch
User
Beiträge: 2353
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Re: PyPy mit Anaconda?

Beitragvon DasIch » Mittwoch 30. November 2016, 23:21

PyPy hat auch einen GIL. Es gibt im Rahmen des PyPy Projektes einen Ansatz den durch Software Transactional Memory (STM) zu ersetzen aber dass ist noch in der Entwicklung. Darüberhinaus ist die einzige Sprache in der man meines Wissens von STM ernsthaft Gebrauch machen kann Haskell. Es ist also nicht unbedingt die einfachste Lösung.

Außerdem können bei STM Transaktionen schief gehen und wenn dass zu häufig passiert muss man wissen was diese Transaktionen überhaupt sind, wieso sie schief laufen können, woran man merkt dass das zu häufig passiert und wie man das Problem löst. So ganz ohne Probleme wäre STM also auch nicht.
consuli
User
Beiträge: 31
Registriert: Sonntag 26. Juli 2015, 22:10

Re: PyPy mit Anaconda?

Beitragvon consuli » Donnerstag 1. Dezember 2016, 20:22

Ich arbeite zur Zeit sehr viel mit grösseren Simulationen (um 1 Mio Datenzeilen aber wenig Spalten), die ich gerne parallelisieren würde. Wenn ich mit Library multiprocessing 1 Mio Prozesse aufmache, kommt das nicht überhaupt nicht gut. Wie kann ich für Numerical Python denn meine Prozessorkerne auslasten?

Consuli
Benutzeravatar
__deets__
User
Beiträge: 627
Registriert: Mittwoch 14. Oktober 2015, 14:29

Re: PyPy mit Anaconda?

Beitragvon __deets__ » Donnerstag 1. Dezember 2016, 21:56

Du sollst ja auch nicht 1000000 Prozesse aufmachen - sondern so viele, wie du Cores/Hyperthreads hast.

Und ob das fuer dein Problem funktioniert kannst nur du wissen. Wenn du du deine 1M Zeilen in 8 Batches zu 125K Zeilen aufteilst & die jeweils an einen Prozess gibst, dann rechnet der das schon in der 8-fachen Geschwindigkeit aus (8 Cores vorausgesetzt).

Nur wenn die einzelnen Berechnungen voneinander abhaengen - dann ist halt essig.
Benutzeravatar
BlackJack
Moderator
Beiträge: 32769
Registriert: Dienstag 25. Januar 2005, 23:29
Wohnort: Berlin
Kontaktdaten:

Re: PyPy mit Anaconda?

Beitragvon BlackJack » Donnerstag 1. Dezember 2016, 22:03

@consuli: Wenn Du eine Million Zeilen mit *wenig* Spalten hast, dann willst Du ganz sicher nicht eine Million Operationen parallel ausführen. Auch nicht ohne GIL. Das macht keinen Sinn. Selbst wenn Du das ganz ”normal” mit `multiprocessing` bearbeitest, also jede Zeile einzeln an einen Prozess fütterst, wird der `Pool` das ja auf eine von Dir sinnvoll gewählte Anzahl von parallelen Prozessen verteilen. Und statt da die Zeilen einzeln zu verteilen, könntest Du auch die Million durch die Anzahl der Prozesse im Pool teilen und jedem Prozess dann den entsprechenden Happen an Daten zum fressen geben.
“XML combines all the inefficiency of text-based formats with most of the unreadability of binary formats :-)” — Oren Tirosh, c.l.p, 2002
consuli
User
Beiträge: 31
Registriert: Sonntag 26. Juli 2015, 22:10

Re: PyPy mit Anaconda?

Beitragvon consuli » Freitag 2. Dezember 2016, 21:29

Ah, ich hatte vermutet ich kann dem multiprocessing die 1 Mio Iterationen in einem Rutsch übergeben und es überlegt sich selbst, wie viele der 1 Mio möglichen Prozesse es dann "im eigenen Ermessen" tatsachlich aufmacht.

Aber ich muss die Daten/ Iterationen zuerst von Hand in 8 mundgerechte multiprocessing Häppchen splitten und nachher die Teile wieder zusammenhängen. Wenn ich 25 rechenintensive Verarbeitungen habe, das ganze 25 Mal oder ich Schleife 8 Teile durch das ganze Programm. Und dann kann ich noch ausklamüsern, ob meine Berechnungen in einem Gesamten Brocken schneller zu Parallelisieren sind oder in Bröckchen. Und für einen anderen Rechner mit 12 Cores schreibe ich das Programm einfach um. Na, das ist ja komfortabel ... :(

Ist das nicht in anderen Programmiersprachen so, wenn ich Threads in einer Schleife laufen lasse, dass der Compiler sie mir AUTOMATISCH auf die Cores legt? Je nach Rechner AUTOMATISCH auf 2, 4, 6, 8, .... Cores?

Consuli
DasIch
User
Beiträge: 2353
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Re: PyPy mit Anaconda?

Beitragvon DasIch » Freitag 2. Dezember 2016, 22:48

Nein ist es nicht, zumindest nicht so wie du dir es vorstellst. Es gibt Bibliotheken die sowas einfacher machen aber vollkommen automatisch und schnell geht nicht.
Benutzeravatar
BlackJack
Moderator
Beiträge: 32769
Registriert: Dienstag 25. Januar 2005, 23:29
Wohnort: Berlin
Kontaktdaten:

Re: PyPy mit Anaconda?

Beitragvon BlackJack » Freitag 2. Dezember 2016, 22:49

@consuli: Das kann gar nicht alles automatisch gehen, weil das sinnvolle Vorgehen ja von den Daten und den Operationen abhängt. Zum Beispiel willst Du bei einem Numpy-Array oder Pandas-Dataframe mit einer Million Zeilen ja gar nicht eine Million einzelne Operationen haben, denn dann verspielst Du eine der wesentlichen Stärken und Geschwindigkeitsvorteile von diesen Datentypen, nämlich die internen Schleifen, die in C, C++, oder Fortran geschrieben sind, und unter Umständen sogar spezielle SIMD-Maschinenbefehle verwenden. Und einiges davon gibt auch das GIL frei, so dass selbst Threads in CPython etwas bringen können.

`multiprocessing` macht für einen Pool (maximal) so viele Prozesse auf, wie Prozessorkerne vorhanden sind. Ausser man macht selber eine Vorgabe.

Auf wie viele Häppchen man ein Problem aufteilt, hängt davon ab wie regelmässig die Laufzeit pro Häppchen verteilt sind. Wenn die alle ungefähr gleich lang brauchen, dann kann man die Gesamtmenge einfach durch die Prozessanzahl teilen. Ansonsten kann es Sinn machen durch ein vielfaches der Prozessorkerne zu teilen. So dass die Prozess gleichmässiger ausgelastet werden können. Das sind auch Entscheidungen die der Rechner nicht automatisch treffen kann. Im Grunde oft nicht einmal der Programmierer ohne das tatsächlich mal mit plausiblen Eingabedaten getestet zu haben.

Warum musst Du für einen Rechner mit 12 Kernen etwas umschreiben? Man kann die Aufteilung dynamisch abhängig von der Anzahl der Kerne machen. Eventuell muss man bei deutlich mehr Kernen etwas experimentieren wie klein Häppchen werden können, bevor das Parallelisieren mehr Aufwand als Nutzen bringt. Auch das kann der Rechner nicht automagisch im voraus entscheiden.

„Threads in einer Schleife laufen lassen“ macht als Aussage für mich keinen Sinn. Threads laufen eigenständig. Und das Betriebssystem weist die in der Regel einem Prozessorkern zu. Der kann im Laufe der Zeit auch wechseln. Das hat nichts mit der Programmiersprache zu tun, sofern Thread hier POSIX Thread meint. Die meisten Programmiersprachen benutzen diese API für Threads. Da ist kein Unterschied zwischen C, Java, …, oder auch CPython. Letzteres startet auch ganz normale Threads, nur hat der Interpreter ein globales Lock, welches verhindert das *Bytecode von der Python-VM* in mehr als einem Thread gleichzeitig ausgeführt wird. Erweiterungsmodule die in C oder einer anderen Sprache geschrieben sind, können dieses Lock freigeben solange sie nichts am Interpreter-Zustand ändern. Also zum Beispiel auch Numpy-Array-Operationen.
“XML combines all the inefficiency of text-based formats with most of the unreadability of binary formats :-)” — Oren Tirosh, c.l.p, 2002
consuli
User
Beiträge: 31
Registriert: Sonntag 26. Juli 2015, 22:10

Re: PyPy mit Anaconda?

Beitragvon consuli » Samstag 3. Dezember 2016, 18:27

Wenn ich NON-Numpy Funktionen und NON-Pandas Funktionen auf TimeSeries oder Dataframe Objekte anwende, dann werden sie zwar vektorisiert (schnellere Schleife), aber nicht parallelisiert, oder doch? In meinem Fall sind die NON-Numpy Funktionen und NON-Pandas Funktionen in Python selbstgeschriebene Funktionen. Und die sind natürlich der Flaschenhals, nicht die allfällig äussere Schleife. Ein Numpy/ Pandas Equivalent gibt es eben nicht. Ich versuche ein neues (von mir zu entwickelndes) GLM Verfahren zu prototypen.

BlackJack hat geschrieben:@consuli: Das kann gar nicht alles automatisch gehen, weil das sinnvolle Vorgehen ja von den Daten und den Operationen abhängt.

Yes, it can. Aber es basiert nicht auf Threads, wie ich vermutete.

Aber zurück zu dem was Python kann. Ich verstehe insbesondere nicht, wie ich die Ergebnisse aus den multiprocessing Subprozessen wieder zusammenfügen soll.

In R (woher ich ja herkomme) ist das sehr elegant gelöst.

Code: Alles auswählen

library(doParallel)

registerDoParallel(cores=8)

result = foreach(i=1:1000000) %dopar% { 
  a=rnorm()
}


Da muss ich mir nix überlegen wie splitten und wie wieder zusammensammeln.
Zuletzt geändert von consuli am Samstag 3. Dezember 2016, 18:49, insgesamt 1-mal geändert.
Sirius3
User
Beiträge: 6012
Registriert: Sonntag 21. Oktober 2012, 17:20

Re: PyPy mit Anaconda?

Beitragvon Sirius3 » Samstag 3. Dezember 2016, 18:42

@consuli: multiprocessing kennt map, was genau das macht, wie Du Dir das vorstellst. Bei numpy-Arrays ist das aber ziemlich langsam, weil wie BlackJack schon geschrieben hat, man eigentlich Vektoroperationen benutzen möchte, statt jeden einzelnen Wert an einen anderen Prozess zu schicken.
Benutzeravatar
BlackJack
Moderator
Beiträge: 32769
Registriert: Dienstag 25. Januar 2005, 23:29
Wohnort: Berlin
Kontaktdaten:

Re: PyPy mit Anaconda?

Beitragvon BlackJack » Samstag 3. Dezember 2016, 19:00

@consuli: No it can't, denn gleich im ersten Absatz steht ja: „Though the quality of automatic parallelization has improved in the past several decades, fully automatic parallelization of sequential programs by compilers remains a grand challenge due to its need for complex program analysis and the unknown factors (such as input data range) during compilation.“

Ausserdem ist das alles auf einer Ebene die nichts mit Python zu tun hat.

Das was Du in R machst, geht wahrscheinlich in Python genau so ohne zu überlegen (ich kenne R nicht so gut als das ich sagen könnte in wie weit das folgende abweicht):
  1. #!/usr/bin/env python
  2. from __future__ import absolute_import, division, print_function
  3. from multiprocessing import Pool
  4.  
  5.  
  6. def do_work(i):
  7.     return i * 2
  8.  
  9.  
  10. def main():
  11.     pool = Pool(8)
  12.     result = pool.map(do_work, xrange(1000000))
  13.     print(result[:20])
  14.  
  15.  
  16. if __name__ == '__main__':
  17.     main()

Aber was genau macht R denn da? Wie trifft es die Entscheidungen? Weisst Du das überhaupt? Und ist das dann auch (zufällig) das was sinnvoll wäre?
“XML combines all the inefficiency of text-based formats with most of the unreadability of binary formats :-)” — Oren Tirosh, c.l.p, 2002
consuli
User
Beiträge: 31
Registriert: Sonntag 26. Juli 2015, 22:10

Re: PyPy mit Anaconda?

Beitragvon consuli » Sonntag 4. Dezember 2016, 12:38

Auf jeden Fall lastet der genannte R Code die Prozessoren aus und liefert das, was er soll. Ob man das noch weiter optimieren könnte, weiss ich nicht.

Ja eben nicht

Code: Alles auswählen

print(result[:20])

Ich will ja den kompletten TimeSeries/ Data.Frame zurück geliefert haben. Kann mir main() denn einen Dataframe zurück liefern?

Ausserdem habe ich im Python Manual gelesen das concurrent.futures nicht nur asynchron sondern auch parallel kann. Käme das auch in Frage?

Gruss und Dank
Consuli
Dav1d
User
Beiträge: 1437
Registriert: Donnerstag 30. Juli 2009, 12:03
Kontaktdaten:

Re: PyPy mit Anaconda?

Beitragvon Dav1d » Sonntag 4. Dezember 2016, 13:47

Ob `concurrent.futures` oder `multiprocessing` ist im Grunde nur eine Frage der API. Ich glaube du hast eine falsche Definition von "asynchron" im Kopf.

`print(result[:20])` gibt nur die ersten 20 Elemente aus, das heisst aber nicht, dass es nur 20 gibt. Result beinhaltet natürlich alle Ergebnisse.
the more they change the more they stay the same
DasIch
User
Beiträge: 2353
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Re: PyPy mit Anaconda?

Beitragvon DasIch » Sonntag 4. Dezember 2016, 14:24

consuli hat geschrieben:Auf jeden Fall lastet der genannte R Code die Prozessoren aus und liefert das, was er soll.

Prozessoren auslasten ist natürlich prinzipiell gut aber die sollen natürlich auch sinnvoll ausgelastet sein.

In der Praxis hast du häufig das Problem dass die Aufteilung und Kommunikation der Daten soviel Zeit kostet dass es sehr häufig schneller ist auf einem Core zu bleiben, gerade bei numerischen Sachen die CPU-bound sind.

Bibliotheken wie parallel (grundsätzlich ziemlich interessant weil es ohne concurrency auskommt) für Haskell und Rayon für Rust lösen dies indem innerhalb der Bibliothek zur Laufzeit entschieden wird was tatsächlich parallel ausgeführt wird und was nicht. Als Benutzer gibst du dann nur noch Hinweise dafür was parallel ausgeführt werden könnte.

Zurück zu „Wissenschaftliches Rechnen“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder