Pyston - JIT-basierte Python Implementation

[Dami123]

Dropbox entwickelt gerade eine JIT-basierte Implementation von Python 2.7. Dropbox entwickelt JIT-basierte Python Implementation Pyston

Was haltet ihr davon, vor alllem, da die Python-Community angesprochen werden soll
Ich finde, die könnten es ruhig für 3.x machen. Ist wohl ein weiterer Schritt zurück in Richtung 2.7.

[EyDu]

Was haltet ihr davon, vor alllem, da die Python-Community angesprochen werden soll

Sie sollten es lassen und lieber in PyPy investieren. Google ist mit Unladen Swallow gegen die Wand gefahren und hat die Geschwindigkeit von PyPy nie erreicht. Was will Dropbox da deutlich besser machen?

[BlackJack]

Wenn's ihnen Spass macht… Ich hätte mich auch über Unterstützung für das PyPy-Projekt mehr gefreut als über einen weiteren Versuch die Sprache komplett neu zu implementieren und etwas eigenes zu probieren.

Irgendwie witzig finde ich ja das Guido sozusagen zur gleichen Zeit Python 2.7 für demnächst beendet erklärt *und* sich wohlwollend zu einem Projekt äussert, welches demnächst eine Python 2.7 Implementierung heraus bringen will.

[anogayales]

Pyston doesn’t support all runtime features (including ones that might introduce slowdowns)

Pyston generally is able to beat CPython’s performance, but still lags behind PyPy.

Das sagt doch schon alles.

[BlackJack]

@anogayales: Naja, PyPy hat auch mal so angefangen. Die Ankündigung von Pyston ist gerade mal 4 Tage alt. Ein bisschen Zeit sollte man ihnen vielleicht schon geben.

[snafu]

Ich halte das Projekt für eine schlechte Idee und kann die Beweggründe von Dropbox nicht nachvollziehen. Auch wirkt Guido ein bißchen unglaubwürdig mit seinem Standpunkt als prominenter Dropbox-Mitarbeiter. Da war er mir zu Google-Zeiten persönlich sympathischer. Was ist denn nun die Zukunft? Python 3 oder irgendwie doch Python 2.7? Oder sollte nur der Privatmensch auf Python 3 setzen und Unternehmen sowie wissenschaftliche Anwender lieber weiterhin (und möglicherweise bis in alle Ewigkeit) auf Python 2.7? Fragen über Fragen...

[Dami123]

Sehe ich genauso. Es gibt zwar mehr Code in 2.7 und wird ggf. immernoch mehr entwickelt, doch werde ich strikt versuchen bei 3.x zu bleiben.

[BlackJack]

Dropbox wird das ja wohl auch für sich selbst entwickeln, und ich schätze mal die haben einfach selber schon sehr viel Python 2.7 Quelltext. Und wenig bis gar keinen Python 3.x Quelltext.

[DasIch]

Das Projekt implementiert Python von Grundauf, ist also nicht ein CPython Fork. Überhaupt Python vollständig zu implementieren und wirklich kompatibel zu CPython zu bleiben ist schon eine gewaltige Aufgabe, schliesslich sind viele Dinge gar nicht wirklich dokumentiert oder klar definiert. Frames z.B. die zwar eigentlich irgendwie Implementationsdetails sind, wenn es an tracebacks usw. geht aber dann letztendlich doch nicht, so dass eine Python Implementation Frames quasi implementieren muss.

In dem Zusammenhang ist es dann auch fraglich inwieweit Pyston überhaupt wirklich schneller als CPython ist, schliesslich tut es auch weniger. Der Vorteil der sich daraus für Pyston ergibt, könnte einen nicht unwesentlichen Teil des Vorsprungs ausmachen.

Dazu kommt bei dem Projekt dass ein richtiger Garbage Collector her soll, also kein Reference Counting, gleichzeitig soll aber Kompatibilität mit CPython geschaffen werden was die C-API angeht. Da wird das Projekt ganz schnell auf die gleichen Probleme wie PyPy stoßen, welches einen Großteil des CPython Verhaltens emuliert so dass die C-API in Kombination mit PyPy sehr langsam ist. Außerdem soll es ein konservativer GC werden, der kann schon gar nicht an die Performce von PyPys inkrementellen generationenbasierenden GC kommen.

Dann soll es ein Method JIT werden und kein Tracing JIT wie PyPy. Im Javascript Bereich werden zwar ausschliesslich Method JITs verwendet und die schlagen sich ganz gut aber da hat auch noch keiner Tracing ernsthaft probiert. Der so ziemlich schnellste JIT LuaJIT, nutzt allerdings Tracing. Ob es mit der Methode überhaupt möglich ist so schnell wie PyPy oder sogar schneller zu werden ist also fraglich, vorallem da PyPy nicht stehen bleibt.

Letztendlich bleibt dann noch das Pyston LLVM nutzt. LLVM ist eine tolle Platform um AOT Compiler zu bauen aber für JITs fehlen da ein paar Features und auch wenn LLVM in dem Bereich aufholt, es gab einige Versuche von den PyPy Leuten LLVM zu nuten, alle sind an fehlenden Features und Bugs in LLVM gescheiert.

[Sirius3]

Ich verstehe nicht, warum hier so herumkritisiert wird, aufgrund von ein paar wenigen Sätzen aus einer Pressemeldung. Hinter Pyston steht eine kommerzielles Unternehmen, das nicht einfach so aus Spaß einen neunen Pythonzweig aufmacht, sondern weil sie ein konkretes Problem haben, das es zu lösen gilt. Eine fertige Lösung einzukaufen ist immer billiger, als eine eigene zu entwickeln, was Zeit, Arbeitszeit und Geld anbelangt. Dass so eine Version nicht hinter verschlossenen Türen entwickelt wird, sondern in aller Öffentlichkeit hat auch keine selbstlosen Gründe. Jede Entscheidung für oder gegen ein Konzept/Algorithmus damit keine akademische Abwägung, welches ist die ideale Lösung, sondern eine wirtschaftliche, welche Bibliotheken lassen sich am einfachsten einbinden, sind am stabilsten usw.
Welcher Tracing-Algorithmus verwendet wird, hängt dann wieder vom Problem ab, das man lösen will. Python hat viel größere Ähnlichkeit mit JavaScript als mit Lua. Die Fortschritte bei Javascript waren in den letzten Jahren enorm, mehrere große Organisationen haben sich einen Geschwindigkeitskampf geliefert, es ist also sehr unwahrscheinlich, dass eine vielversprechende Methode zur Beschleunigung, wie Tracing JIT, nicht in Erwägung gezogen wurde.

[Leonidas]

Dann soll es ein Method JIT werden und kein Tracing JIT wie PyPy. Im Javascript Bereich werden zwar ausschliesslich Method JITs verwendet und die schlagen sich ganz gut aber da hat auch noch keiner Tracing ernsthaft probiert.

TraceMonkey ist nicht ernsthaft?