haskell: wie ist die ausführungsgeschwindigkeit
-
knivil schrieb:
Ganz einfach: sehr schnell. [...] Ich halte "Computer Language Benchmarks Game" halte ich nicht fuer aussagekraeftig.
die Schätzung "sehr schnell" ist natürlich aussagekräftiger als eine Reihe von Benchmarks.
-
Benchmarks einer bestimmten Implementierung eines Problems, die man mit einer bestimmten Implementierung einer Sprache laufen ließ, sagen natürlich viel darüber, "wie schnell Haskell ist".
Über die Probleme des Language Shootout gibt es ganze Reihen von Artikeln.
-
Eben. Ob eine Sprache schnell ist oder nicht, ähnelt der Frage, ob ein Rennrad schnell ist oder nicht. Das hängt ja vom Fahrer ab
Bei Sprachen eben unter anderem vom Compiler, Programmierer und Algorithmus.Zur groben Orientierung können solche Benchmarks aber sehr hilfreich sein.
-
zum Beispiel schrieb:
...
Ein sehr schoenes Bild, das merke ich mir.
-
Die Frage wurde in Bezug auf GHC gestellt.
-
nman schrieb:
Benchmarks einer bestimmten Implementierung eines Problems, die man mit einer bestimmten Implementierung einer Sprache laufen ließ, sagen natürlich viel darüber, "wie schnell Haskell ist".
Über die Probleme des Language Shootout gibt es ganze Reihen von Artikeln.
richtig. Und zum Beispiel der Vergleich den Volkard gepostet hat, umschifft diese Probleme. Da heißt es einfach: Wir haben hier ein set von problemen. Gesucht: schnellstes Programm in jeder Sprache dass diese Probleme löst. Nebenbedingung: Der Code muss Sprachtypisch sein (nicht einfach den C-Code für die C++ implementierung kopieren oder ähnliches). Die Annahme ist einfach: Freaks jeder Sprache wollen versuchen das Problem so effizient wie möglich zu lösen. Hierbei schauen sie voneinander ab, klauen sich ansätze für algorithmen usw. Am Ende, wenn man das ganze sehr lang laufen lässt, müssten dann für alle relevanten Sprachen die Lösungen gegen das Optimum der Sprache konvergieren. Und ab dann kann man vergleichen.
-
otze schrieb:
Freaks jeder Sprache wollen versuchen das Problem so effizient wie möglich zu lösen. Hierbei schauen sie voneinander ab, klauen sich ansätze für algorithmen usw. Am Ende, wenn man das ganze sehr lang laufen lässt, müssten dann für alle relevanten Sprachen die Lösungen gegen das Optimum der Sprache konvergieren. Und ab dann kann man vergleichen.
Aber das hat dann leider auch nichts mehr mit der realen Anwendung (der Sprache(n)) zu tun. Wichtiger als die theoretisch maximale erreichbare Performance ist doch, was man in (knapper) gegebener Zeit realisieren kann und wie performant das dann ist.
-
Tim schrieb:
Aber das hat dann leider auch nichts mehr mit der realen Anwendung (der Sprache(n)) zu tun. Wichtiger als die theoretisch maximale erreichbare Performance ist doch, was man in (knapper) gegebener Zeit realisieren kann und wie performant das dann ist.
Naja, wie willst du das messen? Was ist, wenn du ein solches problem stellst und der Programmierer zufällig mehr mi dem Bereich zu tun hat und dann zum Teil solch optimierten Lösungen aus dem Kopf aufschreiben kann? Dann verlegst du das Problem von den Sprachen auf die Programmierer - auch nicht das Wahre.
-
Bashar schrieb:
Die Frage wurde in Bezug auf GHC gestellt.
Und dennoch wären die dortigen Benchmarks nur dann wirklich spannend, wenn sie die Laufzeiten desselben Codes, den man an n verschiedene Haskell-Compiler verfüttert hat, vergleichen würden.
otze schrieb:
nman schrieb:
[…] Über die Probleme des Language Shootout gibt es ganze Reihen von Artikeln.
richtig. Und zum Beispiel der Vergleich den Volkard gepostet hat, umschifft diese Probleme.
Wovon redest Du? volkard hat einen Link auf genau den Language Shootout gesetzt, von dem ich spreche.
Die Annahme ist einfach: Freaks jeder Sprache wollen versuchen das Problem so effizient wie möglich zu lösen. Hierbei schauen sie voneinander ab, klauen sich ansätze für algorithmen usw. Am Ende, wenn man das ganze sehr lang laufen lässt, müssten dann für alle relevanten Sprachen die Lösungen gegen das Optimum der Sprache konvergieren. Und ab dann kann man vergleichen.
Die Annahme funktioniert aber nur für große weit verbreitete Sprachen mit vielen hinreichend kompetenten Entwicklern, die Zeit und Lust auf derartige Schwanzlängenvergleiche haben.
Ich finde leider gerade einen Artikel eines Lispers, der recht gut erläutert, warum das System für kleine Lisp-Dialekte und andere weniger verbreitete Sprachen bescheuert ist, nicht. Der wäre hilfreich.
-
@ otze: Du kannst es einfach nicht sinnvoll messen. Du kannst allenfalls über mehrere Projekte, Jahre, etc. mitteln und daraus ein Bild ableiten. Übermäßig präzise ist das aber auch nicht, aber dafür auch schön träge (was man z.B. an der Einschätzung der Performance von Sprachen wie Java sieht).
-
auch ein interessanter Benchmark:
q(P) := #erfolgreich beendete Projekte / #fehlgeschlagener Projekte [in der Programmiersprache P]überhaupt sollten Parameter wie Erfolgsquote, Entwicklungszeit, Portabilitätsaufwand und Fehlerquote nicht unterschätzt werden.
-
Korrektur: das ist eine Art benchmarking
-
zum Beispiel schrieb:
auch ein interessanter Benchmark:
q(P) := #erfolgreich beendete Projekte / #fehlgeschlagener Projekte [in der Programmiersprache P]überhaupt sollten Parameter wie Erfolgsquote, Entwicklungszeit, Portabilitätsaufwand und Fehlerquote nicht unterschätzt werden.
Das ist wohl eher ein Benchmark für Projektmanagement. Ob ein Projekt erfolgreich ist, liegt imho so gut wie gar nicht an der Sprache (ausser man wählt krass falsch). Die Entwicklungszeit wird sehr gerne als konstant genommen und wenn die angenommene Entwicklungszeit zu kurz bemessen ist (was die Regel sein dürfte) drückt man überall rum. Damit steigt im Endeffekt die Fehlerrate, allgemein sinkt die Qualität (inklusive Portabilität, Dokumentation, etc.).
-
Aber auch der Benchmark leidet unter dem krassen Problem, dass die Varianz von q für kleine Sprachen enorm hoch ist. So kann Sprache NBM(Nobody Uses Me) mit seinem einen erfolgreichen projekt eine Qualität von 1 haben. Das ist natürlich kein Maßstab
-
Man denke in diesem Zusammenhang auch mal an die Sprache HQ9+. Wie viele fehlgeschlagene "Projekte" wird es wohl in dieser Sprache geben?
Btw: 1 erfolgreiches / 0 fehlgeschlagenes = INF und nicht 1^^
-
Ich habe ein mal etwas rechenintensives in Haskell programmiert, allerdings als blutiger Anfänger. Es gab enorme Schwierigkeiten mit der Geschwindigkeit, ein einfaches C/C++ Programm ohne Tricks und Kniffe war erheblich schneller.
Dafür kenne ich jetzt Haskell ein wenig besser, für ultra-Performance würde ich es persönlich nicht benutzen. Aber vielleicht bin ich dafür zu doof
