Das deutsche Python-Forum

Schon gesehen? Drei Googler wollen mit dem unladen swallow-Projekt (und es ist noch zu klären, ob es um afrikanische oder europäische Schwalben geht, um die Monty-Python-Referenz auch klar zu kriegen) den CPython-2.6-Interpreter modernisieren und so schneller machen. Die ehrgeizige Roadmap umfasst auch den Plan, den GIL auszubauen und so Python fitt für Multikern-Prozessorwelt zu machen. Ich denke, die GAE lässt grüßen...

Ein spannendes Projekt und das erste Release ist schon mal 20% schneller als CPython 2.6 (welches wohl etwas langsamer als CPython 2.5 ist). Dennoch ist der Weg zu 500% schneller noch weit, denke ich. Überbrückt soll er durch den Einsatz der LLVM und eines modernen GC werden. Möglicherweise werden sie sich auf die 64-Bit-Version von Python beschränken. Ich denke, hier könnte man das Speichermodell des Interpreters vereinfachen - einfach weil man mehr Platz hat.

Stefan

Der Nachteil wäre dann ein Dependency auf LLVM und Probleme mit dem portieren auf Architekturen die LLVM nicht unterstützt oder für die es zu groß ist. Aber an sich eigentlich eine tolle Idee und dass die CPython branchen statt LLVMPython zu schreiben macht das ganze noch ein Stück brauchbarer. Wobei wie ich gerade gestern erst wieder festgestellt habe herrscht in python-dev generell eher ein "das kenn ich nicht, das mag ich nicht"-Geist, selbst bei teils recht trivialen Dingen.

Soviel dann zum unvorbelasteten Schluck

Das dürfte interessant werden. Allerdings scheint sich die Begeisterung in #python auch in Grenzen zu halten.

DasIch hat geschrieben:Allerdings scheint sich die Begeisterung in #python auch in Grenzen zu halten.

Haben die da Gründe oder ist es einfach nur die Angst vor dem Anderen?

Ist eine Abhängigkeit von LLVM wirklich so schlimm? Wie groß ist denn diese Bibliothek? Python ist doch auch jetzt schon von anderen Bibliotheken abhängig. Und welche Plattformen würden außen vor bleiben? Falls sie wichtig genug ist, sollte man dann nicht lieber diese auch über LLVM unterstützen statt auf den Performance-Vorteil generell zu verzichten?

Stefan

Ich denke man sollte erst einmal abwarten welche Auswirkungen diese doch drastischen Änderungen haben. Zum Beispiel was C-Module von Drittanbietern angeht. Referenzzähler und GIL haben einen grossen Anteil daran, dass die C-API so aussieht, wie sie aussieht.

Und die Beschleunigung vom ersten Release sind nicht so bedeutsam, weil diese Änderungen ja auch in das normale CPython einfliessen. Das heisst das ist nicht lange ein Vorteil der Schwalbe.

sma hat geschrieben:

DasIch hat geschrieben:Allerdings scheint sich die Begeisterung in #python auch in Grenzen zu halten.

Haben die da Gründe oder ist es einfach nur die Angst vor dem Anderen?

Es scheint da einige zu geben die schon Bescheid wissen ohne sich das überhaupt angesehen zu haben.

Aus den Benchmarks schließe ich, dass es Google um die Performance für die App Engine und andere interne Projekte (möglicherweise auch Blogger) geht. Wenn sie nur die Performance verdoppeln, sparen sie schon 50% ihrer Hardware bzw. können 2x so viele Requests bearbeiten.

Für Python (und die Community) ist das IMHO so ein bisschen eine Bewährungsprobe. Lässt sich Python als Sprache nicht "fit für die Cloud" machen, nimmt seine Bedeutung ab und andere Sprachen werden den Platz einnehmen. Ich erhoffe mir z.B. viel von den Änderungen an der JVM zur effizienteren Methodenwahl für dynamische Programmiersprachen.

Ich finde gut, dass Google nicht ein Gython oder LLVMPython neu bauen will, sondern versucht, das existierende CPython umzuschreiben. Sie könnten auch einfach versuchen, durch die Neuimplementierung eines Subsets von für sich relevantem Python, einfach ihr Problem zu lösen.

http://www.mwscomp.com/movies/grail/grail-23.htm

Klingt interessant. Und es wäre schade, wenn eine schöne Sprache wie Python vom technologischen Fortschritt überholt wird.

Es ist übrigens wohl gerade LLVM-Zeit: MacRuby hat ebenfalls einen experimentellen Branch, der vielversprechende Benchmarks zeigt. Nachteilig scheint dort zu seinen, dass der GC von Objective-C 2.0 benutzt werden muss und dieser offenbar eher miserabel ist.

Die Google-Leute haben übrigens das GC-Problem zu einem eigenen Subprojekt namens "Scarcity" erklärt. LLVM braucht einen universellen GC, von dem auch andere Sprachen profitieren könnten.

Stefan

Das hört sich interessant an. Ich hab auch schon immer Gedacht, das Python unbedingt mit Mehrkern CPUs skalieren sollte, ansonsten wird es immer weniger attraktiv.

Schauen wir mal wohin die Reise geht.

Ich denke mal das größte Problem wird sein, wenn sich die C-API ändern wird und viele externen Module erst angepasst werden müssen. Ich meine deswegen brauchen immer die neuen Python Versionen relativ lange, bis sie alte wirklich ablösen.

PLT Scheme macht es da recht interessant, dort sind nämlich je nach Garbage Collector die C-APIs verschieden. Daher werden die Extensions immer für CGC geschrieben und es gibt dann ein Tool namens xform, dass die Extensions dann auf den 3m-Collector übersetzt (vorrausgesetzt das ist nötig). Diese so übersetzte Datei wird dann kompiliert und kann nun als Modul geladen werden.