Geschwindigkeitsvergleich von Programmiersprachen

OTB · Samstag 24. März 2007, 23:25

Ein sehr interessanter Geschwindigkeitsvergleich (Benchmark) von
Programmiersprachen, mit vielen Optionen
und Einblick in den Quellcode der verschiedenen Testprogramme, ist hier zu bewundern:
http://shootout.alioth.debian.org/gp4sa ... l&lang=all

Leonidas · Samstag 24. März 2007, 23:35

Altbekannt, der Shootout ist eine feste Größe geworden. Ebenso wie dier Win32 Shootout.
Es werden Implementationen und nicht Sprachen verglichen. Sprachen haben keine Ausführgeschwindigkeit. Sie haben nur eine Lerngeschwindigkeit und die ist nicht empirisch messbar.

thelittlebug · Samstag 12. Mai 2007, 17:07

Scheinbar wird hier auch die Qualität des Programmerstellers berücksichtigt, ob ich das ein fairer Vergleich ist wage ich zu bezweifeln.

Wenn man den C Code mit der angeblichen Äquivalenz in z.b. Python oder PHP ansieht kann man unschwer erkennen das die C Programmierer hier eindeutig besser auf "Speed" getrimmt haben.

Schwierig, schwierig, ist glaub ich auch niemals wirklich fair.

lgherby

Leonidas · Samstag 12. Mai 2007, 22:43

thelittlebug hat geschrieben:Wenn man den C Code mit der angeblichen Äquivalenz in z.b. Python oder PHP ansieht kann man unschwer erkennen das die C Programmierer hier eindeutig besser auf "Speed" getrimmt haben.

Wobei Python-Code oft auch mit Absicht nicht auf Geschwindigkeit optimiert ist: Readability counts.
Ich finde als Programmierer ein lesbares Programm besser als ein unlesbares, welches 2% schneller ist.

mawe · Sonntag 13. Mai 2007, 05:58

Leonidas hat geschrieben:Wobei Python-Code oft auch mit Absicht nicht auf Geschwindigkeit optimiert ist: Readability counts.

"Readability counts", bei einem Geschwindigkeitsvergleich? Interessant

Viele der Aufgaben im Shootout kann man in gewissen Programmiersprachen anders/schneller lösen, diese Versionen werden aber von den Leuten dort nicht akzeptiert. Gibt schon einiges an Diskussionen und Kritik dazu.

Zum groben Abschätzen finde ich den Shootout aber ganz gut.

Leonidas · Sonntag 13. Mai 2007, 09:38

mawe hat geschrieben:
Leonidas hat geschrieben:Wobei Python-Code oft auch mit Absicht nicht auf Geschwindigkeit optimiert ist: Readability counts.
"Readability counts", bei einem Geschwindigkeitsvergleich? Interessant

Ja, wenn der Vergleich fair sein sollte, sollte er ja auch typische Programme benchmarken, nicht Programme die so geschrieben sind, dass sie möglichst schnell sind und dadurch weniger verständlich. Wenn man im Shootout die Programme so umschreibt, dass sie nur auf Geschwindigkeit optimiert werden, finde ich dass sie dann nicht mehr typische Python-Programme repräsentieren sondern Sonderfälle.
Typischerweise sind Python-Programme nun mal auf Lesbarkeit getrimmt. Ist in der Regel ja auch ausreichend schnell.

mawe · Sonntag 13. Mai 2007, 10:11

Leonidas hat geschrieben:Ja, wenn der Vergleich fair sein sollte, sollte er ja auch typische Programme benchmarken, nicht Programme die so geschrieben sind, dass sie möglichst schnell sind und dadurch weniger verständlich.

Nun, das sehe ich nicht so. Die Programme sind auch keineswegs "typisch", weil ja oft ein Lösungsweg aufgezwungen wird.

Der Shootout ist IMO weder fair (was immer das in dem Zusammenhang heissen mag) noch objektiv. Aber ich glaube das erwartet auch niemand ernsthaft. Wie gesagt, als grobe Einschätzung ist er recht nett.

Sr4l · Sonntag 13. Mai 2007, 10:26

Aber anders ist ein Vergleich nicht möglich

Mit echtem Code aus echten Einsatzfällen für alle Sprachen zu bekommen ist unmöglich.

Y0Gi · Sonntag 13. Mai 2007, 13:00

Mal ganz davon abgesehen, dass die Sprachen auch ganz unterschiedliche Einsatzgebiete haben und sicher nicht alle für hochperformante Implementierungen gedacht sind oder benutzt werden.

jens · Montag 14. Mai 2007, 07:50

Genau, Python ist bekanntermaßen nicht für hochperformante Sachen geeignet. Das sollte klar sein.
Aber wo ist schon die Performance wirklich wichtig??? Das sind IMHO weniger Bereiche als man eigentlich denkt.

thelittlebug · Montag 14. Mai 2007, 12:57

Es gibt ja immer noch die Möglichkeit in C zu implementieren wenn Geschwindigkeit wirklich ein Kriterium sein sollte.

Das hab ich mal bei einem Feder-Masse System gemacht da ich da mit der Performance alles andere als zufrieden war. Aber dafür war die reine Python Version schnell fertig

Mit C wär ich warscheinlich ein ganzes Wochenende mit dicken Büchern bei der Aufgabe gesessen. Ganz zu schweigen vom dadurch übertriebenen Kaffee, Zigaretten und Lebensmittelmissbrauchs den ich dabei betrieben hätte.

Hätt ich mir aber auch sparen können da es ja PyODE gibt, tja, wenn man solche Details nur schon vorher wüsste

Warscheinlich gibt es jo sowieso für jeden erdenklichen Zweck bereits irgendeine optimierte Version in C die irgendjemand eh schon mal eingebunden hat. Python != LowLevel, und ich finde das auch gut so.

lgherby

jens · Montag 14. Mai 2007, 13:09

Fazit: Python ist gesund für Leib und Seele...

Y0Gi · Montag 14. Mai 2007, 14:38

Einigermaßen komplett würde ein Geschwindigkeitsvergleich zwischen Sprachen erst, wenn man auch noch die Geschwindigkeit aufnimmt, die Hineindenken und Umsetzen in Code in Anspruch nehmen. Dazu noch die Fehlerrate oder Zeit für's Suchen von sprachspezifisch häufigen Problemen (schwer zu findende malloc-Probleme sind außerhalb von C/C++ ja eher selten) und schon sieht das alles ganz anders aus. Und wer Spaß hat, rechnet noch Entwicklungszeit und Betriebskosten gegen, damit sich der Chef ein paar $$$-Statistiken ansehen kann.