PyPy 1.5 kann jetzt Python 2.7
Also ich kenn mich ja jetzt nicht so wirklich aus, deswegen frage ich jetzt einfach mal blauaeugig drauf los.
Warum ist PyPy toll? Ist es "nur" schneller? Ist es ohne weitere Abstriche eine Alternative zu dem klassischen Python interpreter? Funktionieren ueblicherweise alle libraries damit?
Das sind so die Fragen, die ich mir als Hobbyprogrammierer ohne viel Talent da stelle, nachdem ich mir die Startseite des Projektes und das Mission Statement durchgelesen habe...
Warum ist PyPy toll? Ist es "nur" schneller? Ist es ohne weitere Abstriche eine Alternative zu dem klassischen Python interpreter? Funktionieren ueblicherweise alle libraries damit?
Das sind so die Fragen, die ich mir als Hobbyprogrammierer ohne viel Talent da stelle, nachdem ich mir die Startseite des Projektes und das Mission Statement durchgelesen habe...
-
BlackJack
@Nebelhom: Es ist eine Alternative aber kein 1:1-Ersatz zu CPython. Alle Bibliotheken funktionieren zum Beispiel nicht, da es intern ganz anders aufgebaut ist und damit C-Erweiterungen nicht ganz so einfach übernommen werden können (IIRC). Damit fehlt natürlich das eine oder andere Modul was es für CPython gibt.
Neben dem Geschwindigkeitsvorteil gibt es kein "global interpreter lock" (GIL) – das ist der Grund dafür, dass Threads in CPython ihre Arbeit nicht wirklich auf mehrere Prozessorkerne verteilen können. Da Prozessoren heutzutage eher nicht schneller werden, sondern immer mehr Kerne haben, ist das ein ziemlicher Klotz am Bein für CPython.
Ansonsten ist die Technik einfach sehr interessant. Das zum Beispiel ein eingeschränkter Python-Sprachkern besteht (RPython), der in statisch kompiliert werden kann, und damit viel mehr von Python in (R)Python selbst implementiert werden konnte. Je kleiner der Anteil von ”nicht-Python” ist, um so einfacher kann man diesen Teil in anderen Sprachen implementieren und Compiler für andere ”Ziele” schreiben. Zum Beispiel nach Java- oder .NET-Bytecode oder auch andere Sprachen wie JavaScript.
Neben dem Geschwindigkeitsvorteil gibt es kein "global interpreter lock" (GIL) – das ist der Grund dafür, dass Threads in CPython ihre Arbeit nicht wirklich auf mehrere Prozessorkerne verteilen können. Da Prozessoren heutzutage eher nicht schneller werden, sondern immer mehr Kerne haben, ist das ein ziemlicher Klotz am Bein für CPython.
Ansonsten ist die Technik einfach sehr interessant. Das zum Beispiel ein eingeschränkter Python-Sprachkern besteht (RPython), der in statisch kompiliert werden kann, und damit viel mehr von Python in (R)Python selbst implementiert werden konnte. Je kleiner der Anteil von ”nicht-Python” ist, um so einfacher kann man diesen Teil in anderen Sprachen implementieren und Compiler für andere ”Ziele” schreiben. Zum Beispiel nach Java- oder .NET-Bytecode oder auch andere Sprachen wie JavaScript.
PyPy ist verwirrenderweise der Name für zwei eigentlich unterschiedliche Projekte. Dies ist zum einen ein Framework welches erlaubt Interpreter in einem nicht genauer definiertem Subset von Python(RPython) zu schreiben und zu kompilieren. Der Vorteil ist dabei dass es relativ angenehm ist einen Interpreter in RPython zu schreiben und dafür bekommt man einen GC quasi kostenlos und man kann diesen einfach austauschen. Desweiteren hat PyPy einen JIT-Compilter Generator, damit kann man sich mit recht geringem Aufwand einen JIT für einen Interpreter generieren lassen.
Zum anderen hat man halt den Python Interpreter der in RPython geschrieben ist. Die wesentlichen Vorteile bestehen darin dass er einfacher zu warten ist und Änderungen am Interpreter wesentlich einfacher machbar sind als bei CPython. Desweiteren ist die Implementation zu CPython recht kompatibel und wesentlich schneller.
Der einzige Nachteil besteht darin das PyPy die C-API von CPython nicht vollständig unterstützt und dies wahrscheinlich auch nie wirklich wird. Desweiteren muss PyPy einige Sachen wie refcounting usw. für die C-API faken, der Overhead der dabei entsteht kostet einiges an Geschwindigkeit.
@BlackJack PyPy hat einen GIL und es nicht ganz trivial diesen zu entfernen.
Zum anderen hat man halt den Python Interpreter der in RPython geschrieben ist. Die wesentlichen Vorteile bestehen darin dass er einfacher zu warten ist und Änderungen am Interpreter wesentlich einfacher machbar sind als bei CPython. Desweiteren ist die Implementation zu CPython recht kompatibel und wesentlich schneller.
Der einzige Nachteil besteht darin das PyPy die C-API von CPython nicht vollständig unterstützt und dies wahrscheinlich auch nie wirklich wird. Desweiteren muss PyPy einige Sachen wie refcounting usw. für die C-API faken, der Overhead der dabei entsteht kostet einiges an Geschwindigkeit.
@BlackJack PyPy hat einen GIL und es nicht ganz trivial diesen zu entfernen.
hmmm... Hat das Projekt den das Potential CPython abzuloesen?
Wird Pypy schon in projekten benutzt? Kurze google Suche ergab da leider nix. Danke aber schonmal fuer eure Erklaerungen. Ich finde es interessant, einmal ueber den eigenen Tellerrand zu schauen
Wird Pypy schon in projekten benutzt? Kurze google Suche ergab da leider nix. Danke aber schonmal fuer eure Erklaerungen. Ich finde es interessant, einmal ueber den eigenen Tellerrand zu schauen
DasIch hat geschrieben:Desweiteren ist die Implementation zu CPython recht kompatibel und wesentlich schneller.
Code: Alles auswählen
Python 2.7.1 (r271:86832, Feb 7 2011, 11:30:54)
[GCC 4.0.2 20051125 (Red Hat 4.0.2-8)] on linux2
>>> from timeit import timeit
>>> timeit("[k for k in xrange(10**7)]",number=3)
2.4676809310913086
Python 2.7.1 (b590cf6de419, Apr 30 2011, 02:00:34)
[PyPy 1.5.0-alpha0 with GCC 4.4.3] on linux2
>>>> from timeit import timeit
>>>> timeit("[k for k in xrange(10**7)]",number=3)
10.233642101287842
-
lunar
@Nebelhom: Kommt darauf an. In Manchem kann pypy CPython bereits ersetzen. Ein vollständiger Ersatz aber ist vielleicht mittelfristig möglich, aber kurzfristig keinesfalls. Aufgrund der bereits angesprochenen, unzureichenden Unterstützung für in C geschriebene CPython-Module lassen sich viele wichtige Python-Bibliotheken, für die es keine direkte Alternative gibt, nicht mit pypy verwenden. Somit lassen sich mit pypy beispielsweise keine Desktop-Anwendungen schreiben, die auf PyQt, PySide oder pygtk aufbauen. Auch wissenschaftliceh Anwendungen, die numpy und/oder cython nutzen, bleiben außen vor. Ebenso ergeht es Anwendungen, die verbreitete C-Bibliotheken wie lxml nutzen. Mithin lässt sich pypy in wichtigen Gebieten nicht oder nur sehr begrenzt einsetzen.
Konsequenterweise können die großen Linux-Distributoren pypy nicht als Standard-Python ausliefern, da dann viele Programme nicht mehr funktionieren würden (oft auch distributionsspezifische Konfigurationsprogramme). Solange pypy als Standard-Python nicht eingesetzt werden kann, wird es auch CPython unter Linux nicht ablösen, sondern allenfalls mit CPython koexistieren.
Unter Windows ist die Lage anders, da Python dort oft direkt mit einer Anwendung ausgeliefert wird. Mithin ließe sich auch pypy installieren, allerdings natürlich wiederum ohne diverse wichtige Bibliotheken. Zudem ist die Windows-Unterstützung von pypy nach meinem letzten Kenntnisstand nicht vollständig.
@numerix: Nun ja, was sagt das jetzt aus?
Konsequenterweise können die großen Linux-Distributoren pypy nicht als Standard-Python ausliefern, da dann viele Programme nicht mehr funktionieren würden (oft auch distributionsspezifische Konfigurationsprogramme). Solange pypy als Standard-Python nicht eingesetzt werden kann, wird es auch CPython unter Linux nicht ablösen, sondern allenfalls mit CPython koexistieren.
Unter Windows ist die Lage anders, da Python dort oft direkt mit einer Anwendung ausgeliefert wird. Mithin ließe sich auch pypy installieren, allerdings natürlich wiederum ohne diverse wichtige Bibliotheken. Zudem ist die Windows-Unterstützung von pypy nach meinem letzten Kenntnisstand nicht vollständig.
@numerix: Nun ja, was sagt das jetzt aus?
-
BlackJack
@numerix: Jo, wenn man sinnlos 10 Millionen Zahlen kopiert wird man mit der "Unsinniger-Code-Zeitstrafe" belegt.
@lunar: Bei C-Erweiterungen scheint die Unterstützung besser zu sein als ich dachte. Es gibt zumindest einen Ansatz die C-API von CPython zu "faken" und einige Module funktionieren damit wohl auch. Mit Tkinter gibt es schon eine GUI. (Ja ich weiss…) Bei `numpy` gibt es wohl Pläne das direkter unterstützen zu wollen, weil es wohl Interesse von vielen Benutzern gibt.
Ansonsten empfehlen die PyPy-Leute, dass man beim Anbinden von C-Bibliotheken lieber auf `ctypes` setzen sollte, statt eine C-Erweiterung für CPython zu schreiben. Das finde ich ganz unabhängig von PyPy ja auch eine gute Idee. Man braucht dann kein vorkompiliertes Modul für x Python-Versionen auf y Plattformen bereit stellen, beziehungsweise braucht der Endanwender keinen C-Compiler, wenn er es installieren möchte. Und IronPython und Jython haben auch etwas davon.
@lunar: Bei C-Erweiterungen scheint die Unterstützung besser zu sein als ich dachte. Es gibt zumindest einen Ansatz die C-API von CPython zu "faken" und einige Module funktionieren damit wohl auch. Mit Tkinter gibt es schon eine GUI. (Ja ich weiss…) Bei `numpy` gibt es wohl Pläne das direkter unterstützen zu wollen, weil es wohl Interesse von vielen Benutzern gibt.
Ansonsten empfehlen die PyPy-Leute, dass man beim Anbinden von C-Bibliotheken lieber auf `ctypes` setzen sollte, statt eine C-Erweiterung für CPython zu schreiben. Das finde ich ganz unabhängig von PyPy ja auch eine gute Idee. Man braucht dann kein vorkompiliertes Modul für x Python-Versionen auf y Plattformen bereit stellen, beziehungsweise braucht der Endanwender keinen C-Compiler, wenn er es installieren möchte. Und IronPython und Jython haben auch etwas davon.
Generalisierte Aussagen sind halt grundsätzlich falsch.numerix hat geschrieben:Es sagt aus, dass ein Statement wie "ist wesentlich schneller" mit Vorsicht zu genießen ist, weil es eben nicht grundsätzlich stimmt.
-
lunar
@BlackJack: ctypes lässt sich allerdings nicht für C++-Bibliotheken nutzen, und ist nur schlecht dafür geeignet, Python-Code in C auszulagern. Zudem fehlt ctypes noch immer ein automatischer Generator für den Quelltext der Anbindung. Eine manuelle Anbindung ist bei kleinen Bibliotheken zwar gut möglich, bei großen Toolkits wie Gtk oder Qt allerdings unwartbar.
C++-Bibliotheken muss man halt in C wrappen. Ist nicht schön, aber das ist C++ ja sowieso nicht (auch gerade wegen der fehlenden standardisierten Binärschnittstelle). Und gute Bibliotheken haben auch schon ein C-Interface. ctypes hat halt den Vorteil, dass es überall funktioniert, auch mit Jython und Ironpython.lunar hat geschrieben:@BlackJack: ctypes lässt sich allerdings nicht für C++-Bibliotheken nutzen, und ist nur schlecht dafür geeignet, Python-Code in C auszulagern.
-
lunar
@Darii: Große Bibliotheken kann man nicht mal ebenso in C wrappen, zumal man dann zwei Wrapper warten müsste, nämlich einmal von C++ nach C und dann nach ctypes. Da ist es wesentlich einfacher, die C++-Bibliothek direkt auf die CPython-API abzubilden, zumal CPython schon ein Objektsystem bietet, auf dem man aufbauen kann. Mithin gibt es auch beileibe nicht für jede C++-Bibliothek eine äquivalente C-Schnittstelle. Ich wüsste aus dem Kopf heraus nicht eine einzige.
Im Übrigen ist die Binärschnittstelle von C ebenso gut oder schlecht standardisiert wie die von C++. Die C-ABI ist auch nur für bestimmte Kombinationen von Compiler und Plattform standardisiert. Das gilt für C++ ebenso, für Linux und g++ gilt beispielsweise die Itanum C++ ABI. Nur deswegen gibt es ja überhaupt kompatible Compiler. Ansonsten wäre es ja überhaupt nicht möglich, mit dem g++ übersetzte Bibliotheken mit icc oder clang++ zu verwenden.
Es hat sich halt bis jetzt nur niemand die – sicherlich nicht zu unterschätzende – Mühe gemacht, diese ABI in einem "cpptypes" Modul zu implementieren, zumal man aufgrund fehlender unterstützender Bibliotheken (wie libffi im Falle von ctypes) auch wesentlich mehr selbst tun müsste. Da ist es wesentlich einfacher, die zur Verfügung stehenden Binding-Generatoren für C++, die es ja wie Sand am Meer gibt, zu verwenden.
Im Übrigen ist die Binärschnittstelle von C ebenso gut oder schlecht standardisiert wie die von C++. Die C-ABI ist auch nur für bestimmte Kombinationen von Compiler und Plattform standardisiert. Das gilt für C++ ebenso, für Linux und g++ gilt beispielsweise die Itanum C++ ABI. Nur deswegen gibt es ja überhaupt kompatible Compiler. Ansonsten wäre es ja überhaupt nicht möglich, mit dem g++ übersetzte Bibliotheken mit icc oder clang++ zu verwenden.
Es hat sich halt bis jetzt nur niemand die – sicherlich nicht zu unterschätzende – Mühe gemacht, diese ABI in einem "cpptypes" Modul zu implementieren, zumal man aufgrund fehlender unterstützender Bibliotheken (wie libffi im Falle von ctypes) auch wesentlich mehr selbst tun müsste. Da ist es wesentlich einfacher, die zur Verfügung stehenden Binding-Generatoren für C++, die es ja wie Sand am Meer gibt, zu verwenden.
Aber leider nur für cpython. ctypes ist da in den meisten Fällen die eleganteste und beste Lösung.lunar hat geschrieben: Da ist es wesentlich einfacher, die C++-Bibliothek direkt auf die CPython-API abzubilden, zumal CPython schon ein Objektsystem bietet, auf dem man aufbauen kann.
Also gibt es keine einzige gute C++-Bibliothek.Mithin gibt es auch beileibe nicht für jede C++-Bibliothek eine äquivalente C-Schnittstelle. Ich wüsste aus dem Kopf heraus nicht eine einzige.
Mir fällt spontan auch nur llvm ein.Wenn es nur das wäre, das Konzept von Templates verbietet ja auch in weiten Teilen ein definierte Binärschnittstelle.Im Übrigen ist die Binärschnittstelle von C ebenso gut oder schlecht standardisiert wie die von C++. Die C-ABI ist auch nur für bestimmte Kombinationen von Compiler und Plattform standardisiert.
Aber es spricht ja nichts dagegen einen C/ctypes-Binding-Generator zu schreiben. Wenn ctypes-Artige-Module jetzt auch durch Javascript populärer werden, macht das vielleicht auch mal wer.
Es stimmt, bis auf wenige Ausnahmen wie lächerliche Microbenchmarks die keine Aussagen für das Verhalten von echten Programmen zulassen. Ich bin davon ausgegangen dass wäre soweit offensichtlich.numerix hat geschrieben:Es sagt aus, dass ein Statement wie "ist wesentlich schneller" mit Vorsicht zu genießen ist, weil es eben nicht grundsätzlich stimmt.lunar hat geschrieben:Nun ja, was sagt das jetzt aus?
So lächerlich sind diese Mikrobenchmarks gar nicht. Komplex-Benchmarks spiegeln ja oft nur das wieder was zur Zeit mit Python gemacht wird. Und das ist wiederum stark beeinflusst von der derzeitigen Geschwindigkeit der Standard-Implementierung. Niemand macht derzeit reines number-crunching in Python (in reinen Python,... ich rede nicht von C-Erweiterungen). Das ist aber durchaus eine reale Anwendung und es gäbe keinen Grund sowas nicht in Python zu machen wenn die Geschwindigkeit passen würde. Mikrobenchmarks können also durchaus eine reale Anwendung wiederspiegeln.
Einfach mal zu sagen: "Meine Aussage war so nicht richtig" scheint ein schwerer Brocken zu sein ...DasIch hat geschrieben:Es stimmt, bis auf wenige Ausnahmen wie lächerliche Microbenchmarks die keine Aussagen für das Verhalten von echten Programmen zulassen. Ich bin davon ausgegangen dass wäre soweit offensichtlich.
-
lunar
@numerix: Ist Dein Widerspruch nicht auch ein bisschen kleinkariert? Immerhin zeichnet das PyPy Speed Center doch ein relativ deutliches Bild, und zwar mit praktisch einigermaßen relevanten Messungen. Praktische Relevanz kann man Deinem Beispiel bei allem Respekt nicht zugestehen.
@Darii: Stimmt, an Templates hatte ich nicht gedacht. Problematisch sind allerdings nur nicht spezialisierte Templatesin der öffentlichen API, vollständig spezialisierte Templates haben wiederum eine Binärschnittstelle. Allerdings kommt damit nicht mal bei Qt weit. Qt hat zwar nur wenige nicht spezialisierte Template-Funktionen in der öffentlichen API, die aber sind ziemlich essentiell.
@Darii: Stimmt, an Templates hatte ich nicht gedacht. Problematisch sind allerdings nur nicht spezialisierte Templatesin der öffentlichen API, vollständig spezialisierte Templates haben wiederum eine Binärschnittstelle. Allerdings kommt damit nicht mal bei Qt weit. Qt hat zwar nur wenige nicht spezialisierte Template-Funktionen in der öffentlichen API, die aber sind ziemlich essentiell.
OK, dann sollte man es vielleicht ein wenig umformulieren:Praktische Relevanz kann man Deinem Beispiel bei allem Respekt nicht zugestehen.
Code: Alles auswählen
>>> timeit("[k**2 for k in xrange(10**6)]",number=3)
CPython:4.9437051524498656
PyPy:12.076731293408159-
BlackJack
@HerrHagen: Das ist jetzt wirklich praxisrelavanter? Es gibt praxisrelevante wissenschaftliche Programme die nur aus dieser Zeile und nix anderem bestehen? Oder wo diese Zeile wirklich den Kern ausmacht?