Unladen Swallow ist tot

[sma]

...oder ruht jedenfalls (vielleicht neben Cthulhu in R'lyeh) bis die Sterne richtig stehen. So viel als zu dem Versuch von Google, einen schnelleren Python-Interpreter zu schaffen. Die Macher schreiben:

Jeffrey and I have been pulled on to other projects of higher
importance to Google. Unfortunately, no-one from the Python
open-source community has been interested in picking up the merger
work, and since none of the original team is still full-time on the
project, it's moving very slowly. Finishing up the merger into the
py3k-jit branch is a high priority for me this quarter, but what
happens then is an open question.

Bleibt noch Pypy, dessen Fortschritt ich in letzter Zeit nicht mehr verfolgt habe.

Ich glaube, bei all diesen Versuchen gilt das selbe, was auch schon Python 3.x ausbremst. Es ist nicht so viel besser im Vergleich zum "Original". CPython ist einfach gut genug und der Schmerz ist nicht groß genug. Sowohl Python 3.x als auch Unladen Swallow wollten auch nicht zu radikal anders sein. Einerseits eine verständliche Entscheidung, will man doch kompatibel bleiben, andererseits aber fatal, weil es kaum einen Grund gibt, auf das andere zu wechseln.

Edit: Ja, das ist schon "old news", aber ich sah's gerade eben erst auf Hacker News, wo es auch eine (bislang eher wenig interessante) Diskussion zu dem Thema gibt.

Stefan

[DasIch]

PyPy macht momentan sehr grosse Fortschritte. Sie haben einen funktionierenden JIT auf 32 und 64 Bit, mit CPyExt arbeiten sie an Unterstützung für C Extensions und mit 1.5/6 wird es Unterstützung für Python 2.7 geben, woran momentan im fast-forward Branch gearbeitet wird. Desweiteren hat PyPy einen wesentlich geringeren Speicherverbrauch pro Objekt als CPython.

Abgesehen davon ist es die schnellste Implementation momentan; allein mit den letzten 100 Commits sind sie 28% schneller geworden.

Wer keine Lust hat auf 3.x zu wechseln wird über kurz oder lang PyPy nutzen, vorallem weil man auf der Basis auch 2.x relativ einfach "weiterentwickeln" könnte.

[BlackJack]

Ich finde das Projekt auch erfreulich aktiv, aber zu solchen Geschwindigkeitsangaben gehört IMHO immer der "Disclaimer", dass das nicht für jeden Quelltext gelten muss, also das nicht jeder Quelltext auf PyPy schneller laufen muss als auf CPython.

Und wenn man sagt, dass einzelne Objekte wesentlich weniger Speicher belegen, darf man auch nicht unterschlagen, dass insgesamt deutlich mehr Speicher gebraucht werden kann.

[Darii]

Und wenn man sagt, dass einzelne Objekte wesentlich weniger Speicher belegen, darf man auch nicht unterschlagen, dass insgesamt deutlich mehr Speicher gebraucht werden kann.

Das gilt aber nur für JIT-Version. Die JIT-lose soll wohl insgesamt weniger Speicher verbrauchen.

[DasIch]

Die JIT-lose soll wohl insgesamt weniger Speicher verbrauchen.

Ohne JIT ist PyPy allerdings langsamer als CPython, da stellt sich die Frage inwieweit es dann noch interessant ist.

[BlackJack]

@Darii: JIT ist aber eine der interessanten Sachen an PyPy. Ich wollte den höheren Speicherverbrauch in bestimmten Situationen auch nicht als per se schlecht darstellen -- dafür wird der Code ja potentiell schneller. Wollte halt nur auf "tradeoffs" hinweisen. Das gleiche Phänomen hat man bei CPython in Verbindung mit `psyco` ja auch.

[Darii]

Ohne JIT ist PyPy allerdings langsamer als CPython, da stellt sich die Frage inwieweit es dann noch interessant ist.

Naja man hat immer noch die Stackless und Sandboxed-Versionen.

[DasIch]

Stackless hat man momentan leider nur wenn man keinen JIT verwendet.

[Darii]

Stackless hat man momentan leider nur wenn man keinen JIT verwendet.

Genau deswegen habe ich deinen Beitrag auch zitiert. Weil Pypy auch ohne JIT interessante Merkmale hat.