http://psyco.sourceforge.net

Entschuldigung, dass ich Python aus der Liste [Performanz in ProgrammierSprachAuswahl] herausgelöst habe. Das angegebene Tool gibt nur für 386-Architektur und will Code 2-100x beschleunigen. Auch wenn das funktioniert, wird es keinen Performance-Jäger anlocken, sondern zeigt eher wie unkompetitiv Python ohne diese Nachbehandlung ist. -- HelmutLeitner

So herum formuliert ist das falsch. Außenseiter ja, aber Psyco löst kein prinzipielles Problem mit Python, sondern ist ein eigener dynamischer, daten-abhängiger JIT-Compiler für Python-Code, der es manchmal in Sachen Performanz mit C aufnehmen kann. -- DinuGherman

Ich stimme hier Helmut zu. Python fängt gerade an, Erfahrungen mit JIT-Compilern zu machen. Für Smalltalk gibt es die schon sehr lange. Sie sind z. T. schneller als die für Java und trotzdem wird niemand das als Argument pro Smalltalk in dieser Kategorie sehen. Ich kann zwar mit Java, Smalltalk oder Python auch performanzkritische Anwendungen schreiben, muss mich dann aber ständig rechtfertigen, wenn etwas tatsächlich mal zu langsam ist. Eine C++-Anwendung zu verbocken, die langsamer als eine vergleichbare Smalltalk-Anwendung wäre, ist kein abwegiges Szenario. Trotzdem ist C++ an dieser Stelle korrekterweise aufgeführt weil ich im Ernstfall bei entsprechendem Ressourceneinsatz (geschulte Entwickler, ausreichend Zeit, vernünftige Werkzeuge, usw.) immer schneller sein kann als mit Smalltalk oder eben Python. Nur weil Python hier nicht aufgeführt ist, muss das nicht heißen, dass Python komplett ungeeignet wäre. Aber das Standardvorgehen dürfte doch eher die Auslagerung laufzeitkritischer Teile in C-Routinen sein. -- SDö

Das ist ja prinzipiell richtig. Mir gefiel nur nicht die Formulierung unkompetitiv ohne Nachbehandlung, weil dadurch ein generelles Manko ohne diese attestiert wird. Es gibt noch weitere solche Python-Nachbrenner z.B. Stackless und PyPy und vermutlich ähnliches auch für andere Sprachen (früher hatte ich auch mal von einem Smalltalk-nach-C-Konverter gehört...). Und darum geht es doch hier, dachte ich, nämlich zu zeigen, dass für einen speziellen Bereich eine bestimmte Sprache allein kein Hindernis sein muss. Immerhin gibt es (auch Python-) APIs für wissenschatftl. Numerikmodule (in C/Fortran) und Stackless Python wird auch für Ego-Shooter-ähnlichen Kram verwendet. -- DinuGherman

Ein JIT-Compiler für Python, der manchmal X in Geschwindigkeit übertrifft, kann trotzdem im Mittel um 20-50% langsamer sein.

Armin Rigo hat ein paar "animierte Folien" zu seinem Psyco für eine Konferenz bereitgestellt (brauchen PyGame), bei der er das erste mal den Eindruck hatte, die Leute haben es endlich "geschnallt", was Psyco ist. Ich glaube, ich selbst bin noch nicht soweit, war aber auch nicht dabei... ;-) -- DinuGherman (PS: Vielleicht mach ich mal langsam eine eigene Seite dazu auf...)

Die Seite ist jetzt hier. -- SDö

Ich verstehs immer noch nicht. Einen Benchmark zu machen, ohne zu sagen auf welcher Hardware ist sinnlos. Ich sitz gerade auf einem alten AMD 750+, da braucht das qsort auf 100000 ints gerade 0.082 Sekunden, das ist 3x so schnell wie der psyco-Wert? Ein optimiertes C-int-qsort wäre wahrscheinlich 2-3x so schnell (hallo, HelmutSchellong, hörst du mich?). Wenn sie also den Benchmark auf einem 120 MHz Pentium gefahren haben, dann wäre es vielleicht ein guter Wert. -- HelmutLeitner

Psyco does some great things for the performance of certain algorithms, but it's not part of the core Python distribution for any number of reasons: only works on x86, breaks several standard introspection and debugging libraries, and perhaps most importantly, prevents redefinition of methods at runtime on optimized objects. gefunden in comp.lang.ruby, siehe Google-Link

Python eignet sich m.E. sehr wohl für performancekritische Programme. In der Regel ist es so, dass in einem Programm nur sehr wenige, kleine Teile tatsächlich performancekritisch sind. Zunächst sollte man das komplette Programm(system) in Python entwickeln und testen. Das geht viel schneller und einfacher als z.B. mit C++. Nur wenn sich beim Testen herausstellt, dass das System tatsächlich zu langsam ist, ist eine Optimierung überhaupt sinnvoll. Hier hilft dann z.B. ein Profiler. Wenn dann die zu langsamen Bereiche im Programm identifiziert sind, sollte man nochmal einen Blick riskieren, ob vielleicht der Algorithmus per se langsam ist oder schlecht umgesetzt. Und erst danach kann man die infragekommenden Programmbereiche nach C portieren und durch die Python-Implementierung austauschen, was z.B. mit ctypes oder SWIG überraschend einfach geht (auch im Vergleich zu Java). Natürlich läuft C oder C++ schneller als Python, aber nach meiner Erfahrung wird dieser Vorteil häufig dadurch zunichte gemacht, dass man aus Bequemlichkeit einfachere (schlechtere) Algorithmen wählt, z.B. eine Suchschleife anstelle eines Dictionary-Lookups etc, außerdem dauert die Entwicklung um ein Vielfaches länger. In der gleichen Zeit hat man in Python ein gutes Programm geschrieben und schon getestet, so dass man sich auf die wirklich kritischen Stellen konzentrieren kann. Mit Python ist es auch (relativ) einfach, auf Events aus dem Betriebssystem (z.B. Windows Event,Mutex,...) zu reagieren, während man bei anderen Sprachen eher auf Polling zurückgreift - und wenn ein Programm ein Ereignis schneller bemerkt, hat es auch mehr Zeit darauf zu reagieren. --HenningVonBargen