Ich hatte gelesen, dass die Ergebnisse des Unladen Swallow-Projekts (nutze LLVM statt eines Bytecode-Interpreters, um CPython schneller zu machen) statt in CPython 2.x nun in CPython 3.x zurückfließen sollen.
Das könnte dieser Python-Version einen überzeugenden Vorteil verschaffen und so doch noch zu einer Alternative machen.
Gut? Schlecht? Diskutiert es!
Stefan
Unladen Swallow goes Python 3.x
Grundsätzlich finde ich das gut, allerdings stehe ich Python3 in letzter Zeit kritischer gegenüber. Zum einen nervt es ziemlich, dass es immer noch kein WSGI für Python3 gibt, zum anderen habe ich kürzlich gelesen, das irgendwer auf die grandiose Idee gekommen ist, dass die Elemente von ``bytes`` Integer und keine ``bytes`` der Länge eins(oder extra byte-Objekte) sind. Das ist fast so ein Geniestreich wie von Ruby1.9, dass Strings keine Enumerables mehr sind(mag jetzt übertrieben klingen, aber ich habe im 21. Jahrhundert keine Lust mich mit mangelhaften Stringimplementierungen herumzuschlagen, deswegen hatte mich auch Ruby1.8 abgeschreckt und ich habe mir Python näher angeguckt).
So lange WSGI nicht geklärt ist, und es Bibliotheken wie numpy nicht für Python3 gibt, kann es jdenfalls noch so schnell werden, ich werde trotzdem nicht umsteigen.
So lange WSGI nicht geklärt ist, und es Bibliotheken wie numpy nicht für Python3 gibt, kann es jdenfalls noch so schnell werden, ich werde trotzdem nicht umsteigen.
-
Hyperion
- Moderator
- Beiträge: 7478
- Registriert: Freitag 4. August 2006, 14:56
- Wohnort: Hamburg
- Kontaktdaten:
Es wäre schon wünschenswert, wenn Python3 einen Anreiz schaffen würde, der über die reine Verbesserung und Aufräumarbeit hinaus ginge. (Wegen print als Funktion steigt vermutlich kaum einer um - um es mal süffisant auszudrücken). Die Frage bleibt natürlich, ob es nicht stärkere Anreize gäbe, wie z.B. fehlende Libs für Py3. Speziell WSGI ist offensichtlich für viele hier eines der "Killer"-Kriterien für den Verbleib bei Python 2.
@sma: Ich habe mir mal ein wenig den Artikel angeguckt und auch den Überblick zu LLVM (der verlinkte). Allerdings kann ich als ziemlicher Laie auf dem Gebiet nicht wirklich abschätzen, inwiefern ein Unterschied zum bisherigen Weg des Byte-Code Interpreters besteht. Da ich Deine Video-Tutorials bisher exzellent fand, würde ich Dich hiermit mal dazu aufrufen, evtl. ein kleines Beispiel zu implementieren und zu zeigen
Vielleicht kann man anhand eines einfachen Python Konstruktes mal aufzeigen, inwiefern ein LLVM Vorteile bringt? Vielleicht stelle ich mir das auch zu einfach vor, aber wie ich Dich hier bisher einschätze, liebst Du doch solche Heruasforderungen
@sma: Ich habe mir mal ein wenig den Artikel angeguckt und auch den Überblick zu LLVM (der verlinkte). Allerdings kann ich als ziemlicher Laie auf dem Gebiet nicht wirklich abschätzen, inwiefern ein Unterschied zum bisherigen Weg des Byte-Code Interpreters besteht. Da ich Deine Video-Tutorials bisher exzellent fand, würde ich Dich hiermit mal dazu aufrufen, evtl. ein kleines Beispiel zu implementieren und zu zeigen
Vielleicht kann man anhand eines einfachen Python Konstruktes mal aufzeigen, inwiefern ein LLVM Vorteile bringt? Vielleicht stelle ich mir das auch zu einfach vor, aber wie ich Dich hier bisher einschätze, liebst Du doch solche Heruasforderungen Ich glaube ja dass die 2er Reihe wahrscheinlich so lange weiter geführt wird bis der Unterschied zwischen 2.x und 3.x so minimal ist dass ein Umstieg nichts besonderes mehr ist.
Höhere Geschwindigkeit ist in der Python Community sowieso nur selten ein brauchbares Argument, von daher glaube ich nicht dass es irgendeine Rolle spielt womit Unladen Swallow gemerged wird.
Höhere Geschwindigkeit ist in der Python Community sowieso nur selten ein brauchbares Argument, von daher glaube ich nicht dass es irgendeine Rolle spielt womit Unladen Swallow gemerged wird.
Ich glaube Geschwindigkeit spielt eine entscheidende Rolle in der Python Community. Es wird bloß gern kleingeredet weil die Geschwindigkeit momentan nicht da ist.
Ich bin jedenfalls froh das es einen echten Anreiz geben wird auf Python 3 umzusteigen. Mir geht es wie sicherlich den meißten: Ich würde ja gern umsteigen, nur leider stehen noch nicht alle Module mit denen ich arbeite für Python 3 zur Verfügung. Ein großer Geschwindigkeitsunterschied könnte vielen Entwicklern den entscheidenden Schubs geben ihr Paket für Python 3 verfügbar zu machen.
MFG HerrHagen
Ich bin jedenfalls froh das es einen echten Anreiz geben wird auf Python 3 umzusteigen. Mir geht es wie sicherlich den meißten: Ich würde ja gern umsteigen, nur leider stehen noch nicht alle Module mit denen ich arbeite für Python 3 zur Verfügung. Ein großer Geschwindigkeitsunterschied könnte vielen Entwicklern den entscheidenden Schubs geben ihr Paket für Python 3 verfügbar zu machen.
MFG HerrHagen
-
BlackJack
@HerrHagen: Ich glaube Du wünscht Dir das bloss, dass Geschwindigkeit eine grössere Rolle spielt.
Ich sehe das jedenfalls nicht. Zumindest hier und in der englischsprachigen Newsgroup habe ich eher den Eindruck, dass es schnell genug ist, und bei kritischen Stellen einfach genug durch C via `ctypes` oder Cython erweiterbar, als dass das wirklich als wichtiges Problem angesehen wird.
Und was den Schubs angeht: Bringt "unladen swallow" für P3K wirklich so viel? Es geht da ja nur um *Teile* und nicht um LLVM, oder? Falls doch LLVM, was bedeutet das für C-Erweiterungen? Wenn sich da viel ändert, könnte das auch eine neue Hürde sein. Und die Webgeschichten sind damit auch immer noch nicht gelöst. Ebensowenig wie die vielen Entwickler, die erst umsteigen, wenn Python 3 das Standardpython bei den gängigen Distributionen wird.
Ich sehe das jedenfalls nicht. Zumindest hier und in der englischsprachigen Newsgroup habe ich eher den Eindruck, dass es schnell genug ist, und bei kritischen Stellen einfach genug durch C via `ctypes` oder Cython erweiterbar, als dass das wirklich als wichtiges Problem angesehen wird.
Und was den Schubs angeht: Bringt "unladen swallow" für P3K wirklich so viel? Es geht da ja nur um *Teile* und nicht um LLVM, oder? Falls doch LLVM, was bedeutet das für C-Erweiterungen? Wenn sich da viel ändert, könnte das auch eine neue Hürde sein. Und die Webgeschichten sind damit auch immer noch nicht gelöst. Ebensowenig wie die vielen Entwickler, die erst umsteigen, wenn Python 3 das Standardpython bei den gängigen Distributionen wird.
http://renesd.blogspot.com/2010/01/unla ... -work.htmlBlackJack hat geschrieben:Und was den Schubs angeht: Bringt "unladen swallow" für P3K wirklich so viel? Es geht da ja nur um *Teile* und nicht um LLVM, oder? Falls doch LLVM, was bedeutet das für C-Erweiterungen? Wenn sich da viel ändert, könnte das auch eine neue Hürde sein. Und die Webgeschichten sind damit auch immer noch nicht gelöst. Ebensowenig wie die vielen Entwickler, die erst umsteigen, wenn Python 3 das Standardpython bei den gängigen Distributionen wird.
Mein Eindruck aus der SciPy-Community ist eher, dass ctypes, Cython, SWIG, etc. als notwendiges Übel angesehen ist. Am liebsten würden die Leute darauf verzichten, weil es z. T. erhebliche Anforderungen an die Wartung des Codes stellt.BlackJack hat geschrieben:Ich sehe das jedenfalls nicht. Zumindest hier und in der englischsprachigen Newsgroup habe ich eher den Eindruck, dass es schnell genug ist, und bei kritischen Stellen einfach genug durch C via `ctypes` oder Cython erweiterbar, als dass das wirklich als wichtiges Problem angesehen wird.
Im Übrigen finde ich es gut, dass Python so viel konstruktive Kritik erfährt - eben auch durch Projekte wie Unladen Swallow. Bin selber aber passiv und warte halt ab, vor allem, weil ich, wie Darii, zum Entwickeln numpy und Co. benötige und diese Projekte werden immer ihre Anbindung an offzielle Pythonversionen halten wollen und nie auf APIs experimenteller Projekte setzen.
Gruß,
Christian
Also daß 2.6 offiziell und 3.1 experimental ist, hör ich jetzt zum ersten Mal...
Zu den Erweiterungsmöglichkeiten mit C: Ich finde das auch eher hinderlich. Man nutzt Python ja, weil man einfachen/leicht wartbaren Code haben möchte. Man will also möglichst viel in nativem Python schreiben und C nur nutzen, wenn's wirklich sein muss, i.d.R. eben aus Performancegründen. Da kann es nur konsequent sein, dass auch die zeitkritischen Bereiche in der utopischen Zukunft komplett in Python implementiert werden können. Täte Geschwindigkeit in den Augen der Community nichts zur Sache, dann frage ich mich, wieso es diesen beachtlichen Teil an "Tuning-Tools" gibt. Denn als experimentelle Nischenprojekte, die fast nur für den Entwickler selbst interessant sind (oder so "Proof of Concept" mäßig) würde ich die Dinger nicht bezeichnen.
Zu den Erweiterungsmöglichkeiten mit C: Ich finde das auch eher hinderlich. Man nutzt Python ja, weil man einfachen/leicht wartbaren Code haben möchte. Man will also möglichst viel in nativem Python schreiben und C nur nutzen, wenn's wirklich sein muss, i.d.R. eben aus Performancegründen. Da kann es nur konsequent sein, dass auch die zeitkritischen Bereiche in der utopischen Zukunft komplett in Python implementiert werden können. Täte Geschwindigkeit in den Augen der Community nichts zur Sache, dann frage ich mich, wieso es diesen beachtlichen Teil an "Tuning-Tools" gibt. Denn als experimentelle Nischenprojekte, die fast nur für den Entwickler selbst interessant sind (oder so "Proof of Concept" mäßig) würde ich die Dinger nicht bezeichnen.
Entschuldigung - das mußte mißverständlich sein. Ich meine mit experimentell (nicht -tal) Projekte wie Unladen Swallow oder Pypy (auch wenn insb. letzteres inzwischen ziemlich "erwachsen" ist). Natürlich kann man über den Begriff "experimentell" streiten, aber ich hoffe ihr legt ihn nicht auf die Goldwaage. Vielleicht hätte ich schreiben sollen: "not-yet-BDFL-approved"?snafu hat geschrieben:Also daß 2.6 offiziell und 3.1 experimental ist, hör ich jetzt zum ersten Mal...
edit: PS Wenn es jetzt zu weiteren Mißverständlichkeiten kommt - sorry, die kann ich in den nächsten Tagen nicht klären, weil unterwegs ...
-
BlackJack
@snafu: Man kann wahrscheinlich über das Wort "beachtlich" streiten. Was gibt's denn da grossartig, was nicht experimentell ist. Psyco und was noch? Unladen swallow scheint mir jedenfalls genau so ein Nischenprodukt zu sein. Das habe ich zumindest aus dem Blogbeitrag, der weiter oben verlinkt ist, so rausgelesen: Glänzt bei dem was Google selbst braucht, anderes ist nicht deren Ziel, und läuft teilweise sogar langsamer oder gar nicht.
Und zumindest ich möchte zeitkritischen Quelltext nicht *unbedingt* in Python schreiben und ich möchte die einfache Einbindung von C-Code nicht missen. Nicht nur wegen der Geschwindigkeit, sondern hauptsächlich weil es eine Menge nützlicher Bibliotheken gibt, die man damit nutzen kann. Sowas wie die Java-Welt, wo jedes Rad noch einmal neu in Java erfunden wird, möchte ich bei Python nicht sehen. Die Sprache hat ihre Stärken, aber deshalb muss man sie nicht zwanghaft für *alles* verwenden.
Und zumindest ich möchte zeitkritischen Quelltext nicht *unbedingt* in Python schreiben und ich möchte die einfache Einbindung von C-Code nicht missen. Nicht nur wegen der Geschwindigkeit, sondern hauptsächlich weil es eine Menge nützlicher Bibliotheken gibt, die man damit nutzen kann. Sowas wie die Java-Welt, wo jedes Rad noch einmal neu in Java erfunden wird, möchte ich bei Python nicht sehen. Die Sprache hat ihre Stärken, aber deshalb muss man sie nicht zwanghaft für *alles* verwenden.
Mein Beitrag war nicht so gemeint, dass C komplett aus Python raus muss, sondern eher so, dass mehr in Python gemacht werden kann. Und ja, es gibt Psyco, es gibt Jython, es gibt PyPy, es gibt Versuche, Codeteile in JavaScript auszulagern, ... Ich nehme auch an, dass man die ganzen C-Module - nehmen wir mal ein NumPy oder cElementTree - nicht unbedingt ausgelagert werden, weil C so toll ist, sondern eher weil Python zu langsam ist.
-
BlackJack
@snafu: Python ist für bestimmte Dinge zu langsam, na und? Das ist ein Problem was in der Sprache selbst verankert ist, dass zu ändern würde bedeuten die Sprache zu verändern. Und zwar IMHO in eine Richtung wo es dann kein Python mehr ist. Also das was den Teil ausmacht, weswegen ich Python so gerne verwende. Es gibt Teile von Numpy -- Bibliotheken die genutzt werden -- für die ist selbst C "nicht geeignet", da wird Fortran benutzt. Das kann doch nicht bedeuten, dass man Python in Richtung Fortran entwickeln sollte!?
Reines Python ist für "number crunching" zu langsam. Das wird es auch hoffentlich bleiben. `cElementTree` gibt es wohl, weil `ElementTree` für einige Leute zu langsam ist. Ich gehöre nicht dazu. Und das ist ganz ehrlich keine faule Ausrede um mir meine Lieblingssprache schönzureden, sondern ich habe wirklich noch keinen Fall gehabt, wo mir die Geschwindigkeit von `ElementTree` nicht vollkommen ausgereicht hätte. Oft verwende ich `lxml`, aber nicht aus Geschwindigkeitsgründen, sondern weil ich XPath praktisch finde. Und *das* sollte man IMHO nicht in Python nachbauen, weil es schon eine gute C-Bibliothek gibt, die das bereitstellt.
Reines Python ist für "number crunching" zu langsam. Das wird es auch hoffentlich bleiben. `cElementTree` gibt es wohl, weil `ElementTree` für einige Leute zu langsam ist. Ich gehöre nicht dazu. Und das ist ganz ehrlich keine faule Ausrede um mir meine Lieblingssprache schönzureden, sondern ich habe wirklich noch keinen Fall gehabt, wo mir die Geschwindigkeit von `ElementTree` nicht vollkommen ausgereicht hätte. Oft verwende ich `lxml`, aber nicht aus Geschwindigkeitsgründen, sondern weil ich XPath praktisch finde. Und *das* sollte man IMHO nicht in Python nachbauen, weil es schon eine gute C-Bibliothek gibt, die das bereitstellt.
-
lunar
@snafu: Man muss nicht C schreiben, um C zu nutzen. cython ist fast immer die bessere Wahl. Es ist nicht nur lesbarer, sondern oft auch schneller als selbst geschriebener C-Code.
Da ich das Thema gestartet habe, noch ein paar Kommentare von mir.
@Darii: Das Objekte vom Typ `bytes` -- also Byte-Arrays -- aus Zahlen bestehen, finde ich konsequent. Ebenso die fehlende Möglichkeit bei Ruby 1.9, String-Objekte implizit aufzählen zu können. Was soll das tun? Ruby repräsentiert AFAIK Strings als Byte-Arrays plus Encoding und so würde es wenig sinnvoll sein, wenn man dort die Zahlen eines UTF-8-kodierten Strings aufzählen kann. Da muss man also mit `each_byte`, `each_char`, `each_codepoint` oder `each_line` wählen, was man denn nun aufzählen will.
@Hyperion: Die Herausforderung ist interessant, aber im Prinzip macht LLVM auch nichts anderes, als über den Umweg über noch einen Bytecode letztlich Maschinencode zu generieren. Genauso könnte man auch Java-Bytecode erzeugen. Vielleicht passt die LLVM besser zu den Anforderungen als die JVM, aber das Prinzip bleibt das selbe. Und da Java-Bytecode nur eine andere Repräsentation von Java-Quelltext ist, besteht das Geheimnis eigentlich schon fast nur darin, von einer Schleife, die ungefähr so aussieht:
zu etwas zu kommen, das an dieser Stelle so funktioniert:
Weniger Entscheidungen müssen zur Laufzeit getroffen werden, der Code läuft schneller. Da es gerade, was Typanalyse und Micro-Optimierungen der Maschinensprache angeht, nicht einfach ist, wenn man verschiedene Prozessoren unterstützen will, ist es halt praktisch, das einer Bibliothek zu überlassen.
Wie andere (z.B. Snafu) sehe ich es auch so, dass C für höhere Performance nur eine Notlösung ist. Aber ich komme auch aus einer Tradition von Sprachen (Lisp, Smalltalk, Java), die immer versucht haben, alles vom OS bis zur App abzudecken. So profitiert die gesamte Maschine von jeder Optimierung des Laufzeitsystems und jeder Codeteil ist zugänglich und (hoffentlich) verständlich. Das hat natürlich immer so ein bisschen von NIH. Mit der Patchwork-Idee, diese oder jede C-Bibliothek einfach anzuflanschen, konnte ich nie so richtig warm werden. Zudem: Ich möchte, dass ich mit der einen Installation der Sprache alles habe und nicht kompliziert auf andere (fremde) Weise noch dieses und jedes nachinstallieren muss.
@BlackJack: Ich hatte es so verstanden, dass die LLVM-Lösung das C-API von CPython intakt lässt und dazu kompatibel ist.
@Lunar: Cython ist IMHO C mit Python-Syntax, aber kein Python. Das ist noch Mal eine eigene Sprache mit eigenen Regeln. Vielleicht ist diese Sprache einfacher als C, aber sie macht nicht Python schneller. Wenn ich sehe, dass ich Datentypen an Parameter von Funktionen schreiben soll, damit's schneller wird, dann ist das kein Python. Zudem das noch in einer zu Python 3.x inkompatiblen Art passiert. Getypte Parameter machen es zudem nicht notwendigerweise schneller (zumal das statische Typsystem sehr primitiv aussieht) sondern nur den Compiler einfacher. Die korrekte Aussage müsste daher lauten: Bitte schreibe da Typen ran, damit wir, die Compilerschreiber, es einfacher haben, schnellen Code zu generieren. Zumal bin ich mir sicher, dass sich durch das Annotieren von Typen auch die Semantik ändert. Wenn ich "int" annotiere, verliere ich bestimmt doch beliebig große Ganzzahlen und handle mir unbemerkte Über- und Unterläufe von "int" je nach OS-Version bei 32 oder 64 Bit ein.
Ach ja, finde ich's nun gut, dass die Idee da ist, U-S in Python 3 zu mergen? Sagen wir so, es stört mich nicht. Die Performance-Gewinne sind nicht so groß, dass ich morgen schon Python 3 einsetzen will und ansonsten ist es (leider) einfach so: Wegen print als Funktion steigt kaum einer um...
Stefan
@Darii: Das Objekte vom Typ `bytes` -- also Byte-Arrays -- aus Zahlen bestehen, finde ich konsequent. Ebenso die fehlende Möglichkeit bei Ruby 1.9, String-Objekte implizit aufzählen zu können. Was soll das tun? Ruby repräsentiert AFAIK Strings als Byte-Arrays plus Encoding und so würde es wenig sinnvoll sein, wenn man dort die Zahlen eines UTF-8-kodierten Strings aufzählen kann. Da muss man also mit `each_byte`, `each_char`, `each_codepoint` oder `each_line` wählen, was man denn nun aufzählen will.
@Hyperion: Die Herausforderung ist interessant, aber im Prinzip macht LLVM auch nichts anderes, als über den Umweg über noch einen Bytecode letztlich Maschinencode zu generieren. Genauso könnte man auch Java-Bytecode erzeugen. Vielleicht passt die LLVM besser zu den Anforderungen als die JVM, aber das Prinzip bleibt das selbe. Und da Java-Bytecode nur eine andere Repräsentation von Java-Quelltext ist, besteht das Geheimnis eigentlich schon fast nur darin, von einer Schleife, die ungefähr so aussieht:
Code: Alles auswählen
switch(co_code[i++]) {
case PUSH_CONST:
push(co_consts[co_code[i++]])
break;
...
}Code: Alles auswählen
Object t1 = co_consts[3]
Wie andere (z.B. Snafu) sehe ich es auch so, dass C für höhere Performance nur eine Notlösung ist. Aber ich komme auch aus einer Tradition von Sprachen (Lisp, Smalltalk, Java), die immer versucht haben, alles vom OS bis zur App abzudecken. So profitiert die gesamte Maschine von jeder Optimierung des Laufzeitsystems und jeder Codeteil ist zugänglich und (hoffentlich) verständlich. Das hat natürlich immer so ein bisschen von NIH. Mit der Patchwork-Idee, diese oder jede C-Bibliothek einfach anzuflanschen, konnte ich nie so richtig warm werden. Zudem: Ich möchte, dass ich mit der einen Installation der Sprache alles habe und nicht kompliziert auf andere (fremde) Weise noch dieses und jedes nachinstallieren muss.
@BlackJack: Ich hatte es so verstanden, dass die LLVM-Lösung das C-API von CPython intakt lässt und dazu kompatibel ist.
@Lunar: Cython ist IMHO C mit Python-Syntax, aber kein Python. Das ist noch Mal eine eigene Sprache mit eigenen Regeln. Vielleicht ist diese Sprache einfacher als C, aber sie macht nicht Python schneller. Wenn ich sehe, dass ich Datentypen an Parameter von Funktionen schreiben soll, damit's schneller wird, dann ist das kein Python. Zudem das noch in einer zu Python 3.x inkompatiblen Art passiert. Getypte Parameter machen es zudem nicht notwendigerweise schneller (zumal das statische Typsystem sehr primitiv aussieht) sondern nur den Compiler einfacher. Die korrekte Aussage müsste daher lauten: Bitte schreibe da Typen ran, damit wir, die Compilerschreiber, es einfacher haben, schnellen Code zu generieren. Zumal bin ich mir sicher, dass sich durch das Annotieren von Typen auch die Semantik ändert. Wenn ich "int" annotiere, verliere ich bestimmt doch beliebig große Ganzzahlen und handle mir unbemerkte Über- und Unterläufe von "int" je nach OS-Version bei 32 oder 64 Bit ein.
Ach ja, finde ich's nun gut, dass die Idee da ist, U-S in Python 3 zu mergen? Sagen wir so, es stört mich nicht. Die Performance-Gewinne sind nicht so groß, dass ich morgen schon Python 3 einsetzen will und ansonsten ist es (leider) einfach so: Wegen print als Funktion steigt kaum einer um...
Stefan
-
BlackJack
@sma: Also ein ganz kleines bisschen ist Cython schon schneller, auch wenn man nichts weiter annotiert, denn man spart sich die Interpretation des Bytecodes. Anstelle von Bytecodes werden gleich die entsprechenden Aufrufe der Funktionen im Interpreter generiert.
-
lunar
@sma: Ich habe nicht gesagt, dass "Cython" das bessere Python wäre, oder überhaupt die beste Wahl. Ich sage nur, dass Cython die klügere Wahl als "richtiges" C ist, wenn man jetzt vor einer realen Situation steht, in der Python zu langsam ist. Ob Cython nun der richtige Weg oder ein prinzipiell guter Ansatz ist, sei dahingestellt, denn vor allem ist es momentan so ziemlich der bestmögliche Weg, Python relativ komfortabel mit C zu erweitern.