Ist Boo das bessere Python?

[burli]

Um das nochmal zu verdeutlichen. Die Benchmarks, bzw die Ergebnisse derselben, müssen kein direktes Indiz für die Leistungsfähigkeit der Sprache sein sondern sind in erster Linie auf die Fähigkeiten des Programmierers zurückzuführen, der das Programm eingereicht hat.

Wie man sieht gibt es bei manchen Benchmarks einige Sprachen mehrfach, unterschieden durch ein # und eine Zahl. Die Ergebnisse zwischen den einzelnen Programmen unterscheiden sich teilweise dramatisch.

[Leonidas]

Zudem der schnellste Code nicht immer der idiomatische ist, den man so üblicherweise schreiben würde.

[Darii]

Aber am Beispiel von Mandelbrot kann man auch schön sehen, dass Multiprozessing unter Python 3 wohl noch nicht ganz optimal funktioniert, da nur einer der vier Kerne zu 100% ausgelastet wird, die anderen nur jeweils zu rund 15%.

Nein, das deutet vor allem erstmal darauf hin, dass es unter den beim vorherrschenden Testbedingungen irgendwo ein Nadelöhr bei dem Algorithmus gab.

[CM]

Das Python kein Numbercruncher ist ist schon klar.

Du solltest mal ein scipy-Meeting besuchen ...

Aber am Beispiel von Mandelbrot kann man auch schön sehen, dass Multiprozessing unter Python 3 wohl noch nicht ganz optimal funktioniert, da nur einer der vier Kerne zu 100% ausgelastet wird, die anderen nur jeweils zu rund 15%.

... dort würde über das Beispiel eher gelacht. Es ist nämlich nicht sehr pythonisch und insgesamt etwas seltsam.

Also ok, Python ist vielleicht nicht *die* Sprache für numbercrunching, aber man kann viel mit den existierenden (!) Extensions machen. numpy (+ guter Einsatz von multiprocessing, vor allem aber anderer Tools und ggf. auch numexpr zum Speichersparen und ggf. PyTables für performates I/O) ist Dein Freund.
Diese Benchmarks jedenfalls zeigen ein anderes Bild - und sie sind veraltet.

Und Python in HPC? Das ist allerdings noch eine Baustelle ... In anderen Sprachen aber auch.

[burli]

Naja, es steht jedem frei, eigene Versionen einzureichen. Ich weiß allerdings nicht, was alles zulässig ist. Bei C hab ich zumindest mal Boost gesehen. Also sollte Numpy theoretisch auch möglich sein.

Andererseits geht es ja um Python, nicht um C.

[philistion]

Bin gerade auf etwas gestoßen, was ich nun zum ersten Mal sehe und mir sehr hilfreich erscheint um nicht gleich auf SWIG zurückgreifen zu müssen, vielleicht kennt das ja jemand von euch auch noch nicht: http://pyinline.sourceforge.net

[CM]

@philiston: Letzter "News"-Eintrag von 2004 mit Bezug auf (das quasi-tote) PyRex? Scheint mir eher veraltet zu sein.

Hat es mal jemand probiert?

[philistion]

Wirklich, Schade.. es scheint doch kleinere und größere Probleme mit aktuellen Python-Versionen zu geben.

Ich habe aber was vielversprechendes gefunden: http://www.fenics.org/wiki/Instant
Scheint noch aktuell betreut zu werden!

Wollte vorher fast noch schreiben, dass es sich lohnen würde das Projekt (PyInline) zu forken und weiterzubetreiben.. aber mit diesem Fenics - Instant ist das nun wohl nicht mehr notwendig.

[CM]

Schon interessanter - kannte ich nicht.

Was oben von mir unter "andere Tools" verlinkt wurde, ist auch nicht ganz up to date. Hinzuzufügen ist vielleicht Cython. Na ja, und inline und PyRex sind halt zu streichen. (Plus und minus Tools, die ich jetzt nicht im Kopf habe.)

Aber burli hat schon recht - das lenkt vom eigentlichen Thema ab ...

[sma]

Ich wollte mich eigentlich noch darüber echauffieren, dass dieses "Benchmark *Game*" ein klarer Fall von "Wer misst, misst Mist" ist, weil z.B. einige Benchmarks je nach Sprache mal Multiprozessing benutzen und mal nicht und weil z.B. die Algorithmen unterschiedlich sind und sowieso nirgends eine Analyse gemacht wird, was da eigentlich gebenchmarkt wird, aber ich glaube über das Thema ist genug gesagt worden. Also schweige ich lieber :)

Stefan

[nemomuk]

Ganz interessant zu Performance bzw. Threading in Python... http://blip.tv/file/3254256/

Insbesondere diese Seite hier: http://dabeaz.com/GIL/gilvis/index.html

[burli]

Ich wollte mich eigentlich noch darüber echauffieren, dass dieses "Benchmark *Game*" ein klarer Fall von "Wer misst, misst Mist" ist, weil z.B. einige Benchmarks je nach Sprache mal Multiprozessing benutzen und mal nicht und weil z.B. die Algorithmen unterschiedlich sind und sowieso nirgends eine Analyse gemacht wird, was da eigentlich gebenchmarkt wird, aber ich glaube über das Thema ist genug gesagt worden. Also schweige ich lieber

Deshalb sehe ich es eher als Spiel oder Wettbewerb für Programmierer als einen absolut aussagekräftigen Benchmark für Sprachen. Hier sind die Programmierer gefordert, einen möglichst idealen Algorithmus für "ihre" Sprache zu programmieren. Wenn dazu die Nutzung der Multicore Prozessoren gehört ist das doch gut. Schließlich ist das die Zukunft.

Wie man in dem Video von SchneiderWeisse sieht (im übrigen sehr interessant, thx) ist die aktuelle Implementierung von CPython nicht nur nicht in der Lage, mehrere Kerne zu nutzen sondern läuft auch noch schlechter als auf einem Single Core.

Es ist doch im Interesse aller, wenn es hier Verbesserungen gibt. Wenn so ein Benchmark zum finden und lösen solcher Probleme beiträgt ist das doch auch nicht verkehrt.