IronPython und Mono

Probleme bei der Installation?
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Beitragvon burli » Sonntag 3. August 2008, 12:02

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.
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Sonntag 3. August 2008, 12:16

burli hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Beitragvon burli » Sonntag 3. August 2008, 12:28

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
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Sonntag 3. August 2008, 12:34

burli hat geschrieben: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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Sonntag 3. August 2008, 19:57

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
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Sonntag 3. August 2008, 20:01

sma hat geschrieben: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ß.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Sonntag 3. August 2008, 20:26

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
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Montag 11. August 2008, 10:47

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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Beitragvon burli » Montag 11. August 2008, 10:56

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
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Montag 11. August 2008, 12:05

burli hat geschrieben:Wo finde ich denn die Sourcen für den Benchmark.

Im Python SVN-Tree.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Beitragvon burli » Montag 11. August 2008, 12:19

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)
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Montag 11. August 2008, 13:28

(use --debug to display the traceback)
My god, it's full of CARs! | Leonidasvoice vs Modvoice
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Beitragvon burli » Montag 11. August 2008, 13:33

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

Bild

Er scheint etwas auszugeben, aber man kann nix lesen
burli
User
Beiträge: 1116
Registriert: Dienstag 9. März 2004, 18:22

Beitragvon burli » Montag 11. August 2008, 13:36

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
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Mittwoch 13. August 2008, 08:41

Leonidas hat geschrieben: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

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder