Performance?

[tux.]

C-ähnliche Performance als Argument?

Hm.
Lisp!

[pythoneer]

tux. schrieb:
--------------------------------------------------------------------------------
> C-ähnliche Performance als Argument?
>
> Hm.
> Lisp!

Pah! Haskell!

[DrWatson]

Lisp ist doch fast immer deutlich langsamer als C.

Those who cannot remember the past are condemned to repeat it.
–George Santayana

[tux.]

Das stimmt nicht.

[Hello_World]

Doch, tut es.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=sbcl&lang2=gcc
Also erzähl doch deine Märchen bitte woanders.

[kim3000]

Hello_World schrieb:
--------------------------------------------------------------------------------
> Doch, tut es.
> benchmarksgame.alioth.debian.org
> Also erzähl doch deine Märchen bitte woanders.

Ich will ja jetzt nicht LISP in Schutz nehmen aber diese debian.org Benchmarks verbreiten seit Jahren einfach nur totales Unwissen.

Diese Benchmarks die die da verwenden sind uebel kurz. Unglaublich simpel. Unglaublich praxisfremd. Wenn ich versuchen wollte fuer nativen Code einen positiv-biased Benchmark zu schreiben, wuerde ich es genau so wie diese Jungs machen.

Zweitens und noch um einiges wichtiger: viele Sprachen kompilieren nicht direkt zu ausfuehrbarem Code sondern bringen einen Interpreter, eine VM oder sonstwas mit um den Code auszufuehren. Dieser Interpreter bzw. VM muss erstmal gestartet werden. Es muessen 1001 Resourcen geladen werden usw. Bei einem saukurzen Benchmark macht diese Startup-Time unglaublich viel aus. Wuerde so ein Benchmark eine Stunde oder gar ein Tag laufen wuerde es nur noch wenig ausmachen. So kurz wie die Benchmarks ausgelegt sind muss man schon absichtliche Benachteiligung einiger Sprachen unterstellen.

Bei nativem Code, wie C-Code ist die Laufzeitumgebung das OS. Man muesste also erstmal irgendwie reinrechnen wie lange es dauert bis das OS gebootet ist. Tut man aber nicht. Bei nativem Code misst man die REINE Ausfuehrungszeit. Brutal unfair.

[Schnarchnase]

kim3000 schrieb:
--------------------------------------------------------------------------------
> Brutal unfair.

Absolut nicht. Man muss sich nur vor Augen halten was die Debian-Leute mit den Sprachen tun – ein Betriebssystem bauen. Ich vermute mal genau darauf zielen auch die Benchmarks ab und genau da sind VMs eher problematisch, wenn es nicht gerade um Services geht die dauerhaft laufen.

Also alles gut, man sollte sich nur genau durchlesen und begreifen was diese Benchmarks zeigen und was eben nicht. Der Ablauf wird hier genau erklärt: http://benchmarksgame.alioth.debian.org/play.html

Im Endeffekt ist jeglicher Benchmark nur ein groben Anhaltspunkt, realistische Werte kann keiner liefern.

[kim3000]

Schnarchnase schrieb:
--------------------------------------------------------------------------------
> kim3000 schrieb:
> ---------------------------------------------------------------------------
> -----
> > Brutal unfair.
>
> Absolut nicht. Man muss sich nur vor Augen halten was die Debian-Leute mit
> den Sprachen tun – ein Betriebssystem bauen. Ich vermute mal genau
> darauf zielen auch die Benchmarks ab und genau da sind VMs eher
> problematisch, wenn es nicht gerade um Services geht die dauerhaft laufen.
>
> Also alles gut, man sollte sich nur genau durchlesen und begreifen was
> diese Benchmarks zeigen und was eben nicht. Der Ablauf wird hier genau
> erklärt: benchmarksgame.alioth.debian.org
>
> Im Endeffekt ist jeglicher Benchmark nur ein groben Anhaltspunkt,
> realistische Werte kann keiner liefern.

So allgemeine Positionen kann ich gerne auch vertreten. Die Debian Benchmarks haben ihre sehr eingegrenzte Berechtigung. Nur werden Sie immer und immer wieder von Leuten zitiert wenns um Performance geht wo sie eben nicht hinpassen.