IronPython und Mono

[burli]

Ich grabe zwar eine olle Kamelle aus, aber ich bin grad drüber gesolpert.

IronPython scheint, wenn man diesem Benchmark glauben darf, deutlich langsamer als normales Python und braucht mehr Speicher. Unter Mono wird IronPyhon dann wohl auch nicht viel besser laufen.

[Leonidas]

IronPython scheint, wenn man diesem Benchmark glauben darf, deutlich langsamer als normales Python und braucht mehr Speicher. Unter Mono wird IronPyhon dann wohl auch nicht viel besser laufen.

Ich denke dass dies schon unter Mono ist, wenn man davon ausgeht, dass es kein Windows Gentoo gibt.

[burli]

Unten drunter steht

IronPython 1.1.1 (1.1.1) on .NET 2.0.50727.42

Daher nehme ich an das es sich um .NET 2.0 handelt, nicht um Mono

[Leonidas]

Unten drunter steht

Eigentlich steht das erst da, wenn man die Sprachen-Reihenfolge vertauscht.

Und auf der Hauptseite steht: """Python IronPython scripting for .net (mono is not ms .net) """. Anders wäre das ja auch seltsam, .NET auf Wine auf Gentoo für den Benchmark nutzen? Noch dazu das Mono tatsächlich manchmal diese Versionsnummer ausgibt.

[sma]

Für den zitierten Benchmark gilt wahrscheinlich auch die allgemeine Regel: "Traue keinem Benchmark, den du nicht selbst gefälscht hast" ;)

Zu Beginn des IronPython-Projekts wurde verbreitet (und nicht dementiert), dass IronPython (Version 1) messbar schneller als CPython (Version 2.4) war (Faktor 1,3 bis 1,7 wurde genannt). Ich denke nicht, dass IronPython langsamer geworden ist. Und ob CPython 2.5 so viel schneller als 2.4 ist, bezweifel ich ebenfalls. Definitiv gilt, dass IronPython unter Microsofts .NET entwickelt und getestet wurde und das diese Version signifikant schneller ist als Mono. Aktuell ist zudem IronPython (2.0 beta 3), welches wahrscheinlich nochmals schneller ist als IronPython 1.1 - jedenfalls unter Microsofts .NET VM. Für irgendwas müssen ihre CallSite-Objekte (die polymophic inline caches implementieren, die derzeit beste Technik, um dynamische Methodensuche zu beschleunigen) der DLR doch gut sein...

Ich habe auf die Schnelle leider keinen anderen Benchmark gefunden, der die Versionen unter Windows und nicht unter Linux (mit Mono .NET) vergleicht. Ich vermute aber, da sieht das anders aus. Auch ist bestimmt nochmal die Mono-Version entscheidend, da auch hier die VM kontinuierlich besser wird.

Das sich IronPython die Performance mit höherem Speicheraufwand erkauft, sollte klar sein. Ebenso wird die Startzeit bedingt durch die VM-Technologie größer sein - beides ist aber für viele Anwendungen egal, da es dort um länger laufende Prozesse gibt, wo man Speicher und Startzeit gerne gegen zusätzliche Performance tauscht.

Ansonsten hätte ich die Hoffnung, dass wenn man die gleichen Optimierungen, die IronPython macht, für Jython und die Java-VM portiert und so die deutlich besseren Optimierungen der Hotspot-VM gegenüber Microsofts .NET VM nutzen kann, ein wirklich schnelleres Python erreicht - ähnlich wie JRuby inzwischen auch schneller als Ruby ist. Letzteres ist aber vielleicht auch wiederum nicht so schwer, trägt doch Ruby voller Stolz das Schlusslicht bei der Performance von Scriptsprachen :)

Stefan

[Leonidas]

Das sich IronPython die Performance mit höherem Speicheraufwand erkauft, sollte klar sein. Ebenso wird die Startzeit bedingt durch die VM-Technologie größer sein - beides ist aber für viele Anwendungen egal, da es dort um länger laufende Prozesse gibt, wo man Speicher und Startzeit gerne gegen zusätzliche Performance tauscht.

Wenn es nach Microsoft ging, gäbe es mehr .NET-Applikationen und somit wären zumindest die Kernbibliotheken von .NET sowieso im Speicher, da wäre der Aufwand neue Programme zu starten gar nicht mal so groß.

[sma]

Nachtrag: Im April 2007 hat der Autor CPython 2.5 mit IronPython 1.1 unter Windows vergleichen: ipy = 1,7x cpy.

Zu diesem Zeitpunkt war Mono langsamer als Windows .NET.

Update 1: Hier hat google noch einen Benchmark von Jython 2.3 vs. CPython 2.4 ausgegraben. Jython erreicht 72% der Performance, ist also langsamer. (Ich finde ja nett, dass der Testrechner Cthulhu heißt... Netter Namensraum für Rechner. Wie wäre es mit Shub-Niggurath oder Ghatanothoa...

Update 2: Habe jetzt sebst Pybench für CPython 2.5 und Jython 2.5a1 ausgeführt. Mein Mac hat keinen so schicken Namen, braucht dafür nur ca. 6.3sek für den Benchmark. Jython schlägt sich mit der Java 1.6 64-bit-Server-VM recht gut. Nach einigen Aufwärmrunden liegt die Zeit ebenfalls bei 6.3sek. Dafür braucht Jython aber ~70 MB Hauptspeicher, nicht ~5MB wie CPython. Auch schafft es Jython, 150% CPU-Leistung zu ziehen, während CPy bei 99% bleibt. Java 1.5 Server (32-bit) bringst nicht und bleibt bei etwa 7sek stehen. Dafür braucht es "nur" ~50MB. Java 1.5 Client (32-bit) ist mit 11sek Schlusslicht.

Stefan

[Leonidas]

Super dass mal jemand das wieder getestet hat, schade nur dass ohne IronPython. Aber das könnte man unter Mac wohl nur auf Mono testen. Ales in allem scheint aber IronPython für Linux-Setups generell eher wenig interessant zu sein, denn Mono wird immer noch eine schlechte Performance nachgesagt. :-/ Konkrete Messungen habe ich aber dazu nicht gesehen.

Apropos Java-Benchmarks wäre es generell mal interessant wie sich die verschiedenen Sprachen auf der JVM (etwa JRuby, Jython, Scala, Clojure) bei den gleichen Aufgaben schlagen.

[burli]

Wo finde ich denn die Sourcen für den Benchmark. Vielleicht kann ich hier mal CPython und IronPython (Mono) miteinander vergleichen. Wenn Ich Windows dazu überreden kann IronPython zu verwenden kann ich es da auch mal testen

[Leonidas]

Wo finde ich denn die Sourcen für den Benchmark.

Im Python SVN-Tree.

[burli]

Hm, bei mir spuckt IronPython einen Fehler aus

Code: Alles auswählen

~/pybench$ ipy pybench.py
-------------------------------------------------------------------------------
PYBENCH 2.0
-------------------------------------------------------------------------------
* using Python 2.4.0 (IronPython 1.1.1 (1.1.1) on .NET 2.0.50727.42)
* Python version doesn't support gc.disable
* Python version doesn't support sys.setcheckinterval
* using timer: time.time


* Internal Error (use --debug to display the traceback)

[Leonidas]

(use --debug to display the traceback)

[burli]

Hab ich schon probiert. Da kommt nur etwas sehr merkwürdiges bei raus. Irgendwas stimmt da nicht



Er scheint etwas auszugeben, aber man kann nix lesen

[burli]

Korrektur: er hat was ausgegeben, aber in der gleichen Farbe wie der Hintergrund. War nicht zu erkennen

Code: Alles auswählen

~/pybench$ ipy pybench.py --debug
-------------------------------------------------------------------------------
PYBENCH 2.0
-------------------------------------------------------------------------------
* using Python 2.4.0 (IronPython 1.1.1 (1.1.1) on .NET 2.0.50727.42)
* Python version doesn't support gc.disable
* Python version doesn't support sys.setcheckinterval
* using timer: time.time

Traceback (most recent call last):
  File CommandLine, line unknown, in __init__
  File pybench, line unknown, in main
  File pybench, line unknown, in __init__
  File pybench, line unknown, in __init__
  File pybench, line unknown, in get_machine_details
  File platform, line unknown, in python_build
  File platform, line unknown, in _sys_version
AttributeError: 'NoneType' object has no attribute 'groups'

[sma]

Apropos Java-Benchmarks wäre es generell mal interessant wie sich die verschiedenen Sprachen auf der JVM (etwa JRuby, Jython, Scala, Clojure) bei den gleichen Aufgaben schlagen.

Ich denke, das ist recht schwer, hier aussagekräftige Benchmarks zu finden. Der Programming Language Shootout kann ein Indiz sein, aber das fehlen Jython und Clojure.

Ich würde tippen, dass Java selbst die Liste anführen würde. Danach kommt dann Scala, was bei gleicher semantischen Komplexität auch in etwa den gleichen Bytecode erzeugen wird und damit von der Laufzeit vergleichbar ist. Hier wäre höchstens interessant, wie viel z.B. eine rein funktionale Lösung an Laufzeit kostet. Ich tippen weiter, dass dann Clojure folgt, welches sich ebenfalls recht stark an den Möglichkeiten bzw. Unmöglichkeiten der JVM orientiert und etwa den Anwender zwingt, auf Rekursion zu verzichten und statt dessen `recur` und `loop` Specialforms einzusetzen. JRuby ist dann schneller als Jython, in erster Linie, weil dort wesentlich mehr Arbeit in die Optimierung geflossen ist. Beide Sprachen wehren sich eigentlich mit Händen und Füßen, in ein so starres Konzept wie die JVM gepresst zu werden und man muss viel Überredungskunst in Form von komplizierten Optimierungen einsetzen, um da etwas zu reißen.

Eine sehr schnelle und dennoch einfache JVM-basierte Scriptsprache ist übrigens Pnuts und Rhino (JavaScript) sollte man auch nicht vergessen. Dann wäre auch ein Blick auf ein echtes Scheme (SISC) oder CommonLisp (ABCL) interessant. Und natürlich darf man Groovy nicht vergessen.

Übrigens, den Ansatz von Cython, also ein Subset von C mit Syntax von Python, welches sich leicht und effizient in C übersetzen lässt aber dennoch für Python-Entwickler eine vertraute Syntax bietet, müsste man doch auch für Java einsetzen können. Ähnlich fing ja Groovy an - man wollte etwas wie Java, das sich aber mit weniger Schmerzen schreiben lässt. Und auch RPython fällt doch in diese Kategorie - ein um dynamische Features beraubtes Subset von Python, welches sich effizient in eine statische Programmiersprache übersetzen lässt.

Stefan

[burli]

Den Sinn von einer Scriptsprache in einer Scriptsprache verstehe ich eigentlich nicht. Bei IronPython hatte ich mir eigentlich mehr Performance erhofft weil ich dachte Python wird in IML übersetzt und das wird letztendlich nativ compiliert. Aber das war wohl ein Trugschluss. Vielmehr ist wohl der Python Interpreter in C# implementiert

[Leonidas]

Und auch RPython fällt doch in diese Kategorie - ein um dynamische Features beraubtes Subset von Python, welches sich effizient in eine statische Programmiersprache übersetzen lässt.

Also meinst du RPython auf der JVM?

Was die Performancereihenfolge angeht hätte ich da ganz ähnlich geschätzt, lediglich Scala habe ich mir nicht ausreichend angesehen und da schätzen zu können. Was aber die Limitierungen der JVM angeht hat Rich Hickey (die treibende Kraft hinter Clojure) meiner Meinung nach noch Tail-Call-Optimization in Zukunft nachzuholen denn ``recur`` scheint drangekleistert zu sein, nicht so wie in Scheme. Zudem das Problem eigentlich lösbar ist, denn soweit ich weiß unterstützt Bigloo auf der JVM TCO ohne Probleme. Man muss es eben selbst Optimieren, da die JVM sowas nicht selbst kann, aber es ist nicht ausgeschlossen dass spätere Clojure-Versionen das nachrüsten wenn mehr Interesse da ist.

Den Sinn von einer Scriptsprache in einer Scriptsprache verstehe ich eigentlich nicht. Bei IronPython hatte ich mir eigentlich mehr Performance erhofft weil ich dachte Python wird in IML übersetzt und das wird letztendlich nativ compiliert. Aber das war wohl ein Trugschluss. Vielmehr ist wohl der Python Interpreter in C# implementiert

Da vermischst du etwas.

IronPython-Programme werden (zumindest als ich zuletzt reingeschaut habe) ja auch in IL kompiliert, nur ist dieser Code nicht so einfach wie der entsprechende C# Code und braucht länger in der Ausführung, weil eben bei Python zur Laufzeit mehr passiert.

Der IronPython-Interpreter ist aber weder in Python noch in IL geschrieben. Analog dazu ist der CPython Interpreter in C geschrieben und produziert ebenso Bytecode, nur eben Python-Bytecode.

[burli]

Der IronPython-Interpreter ist aber weder in Python noch in IL geschrieben. Analog dazu ist der CPython Interpreter in C geschrieben und produziert ebenso Bytecode, nur eben Python-Bytecode.

Aber Python Bytecode wird doch direkt interpretiert. .NET wird zur Laufzeit in nativen Code compiliert, oder?

[Leonidas]

Aber Python Bytecode wird doch direkt interpretiert. .NET wird zur Laufzeit in nativen Code compiliert, oder?

Ja, durch den JIT-Compiler. Aber das ist keine .NET-Spezialität, das haben die JVM, PLT Scheme, PyPy und viele andere auch.

Fakt ist: auch wenn man den Code zu nativen Code kompiliert, ist es langsamer als C#, schlicht weil eben mehr Code ausgeführt werden muss.

[burli]

Ja, durch den JIT-Compiler. Aber das ist keine .NET-Spezialität, das haben die JVM, PLT Scheme, PyPy und viele andere auch.

PyPy ist ein JIT? Das verwirrt mich jetzt weil bei mir pypy ein Python in Python Interpreter ist