Programming language shootout

nman

dsffdsdf schrieb:

http://shootout.alioth.debian.org/

Wie aussagekräftig ist dieser Test?

Nur sehr begrenzt. Gibt schon zahlreiche Threads dazu.

Kann ich davon ausgehen, dass C und C++ wirklich die schnellsten sind?

Du kannst auf alle Fälle davon ausgehen, dass sich C- und C++-Programme gut dahingehend optimieren lassen, dass sie schnell sind und das bei den Language-Shootout-Programmen auch passiert.

dsffdsdf schrieb:

Kann ich davon ausgehen, dass C und C++ wirklich die schnellsten sind?

du kannst davon ausgehen, dass man auch dmit lahme SW schreiben kann.

dsffdsdf schrieb:

Kann ich davon ausgehen, dass C und C++ wirklich die schnellsten sind?

merkwürdig, daß zwar C, C++, Fortran und Assembler genannt wurden, aber nicht Forth.

Auf Maschinencode compiliert, können Forth-Programme äußerst effizient laufen.

Da man in Forth gerne jede erkennbare Code-Redundanz in neu definierte Wörter auslagert, sind Forth-Programme dazu oft noch äußerst kurz.

_--

und schrieb:

dsffdsdf schrieb:

Kann ich davon ausgehen, dass C und C++ wirklich die schnellsten sind?

du kannst davon ausgehen, dass man auch dmit lahme SW schreiben kann.

lieber ne sprache welche bei programmierfehlern langsam wird, als eine die einfach nicht schneller geht. sonst fühlst dich wie in ner lahmen kiste ne steigung hoch fahrend auf dem sitz wippend/gaspedal pumpend in der hoffnung das ding geht doch iwie schneller

volkard

!rr!rr_. schrieb:

dsffdsdf schrieb:

Kann ich davon ausgehen, dass C und C++ wirklich die schnellsten sind?

merkwürdig, daß zwar C, C++, Fortran und Assembler genannt wurden, aber nicht Forth.

Vielleicht, weil sich kein Forth-Einsender fand. Soo oft word Forth ja leider nicht mehr eingesetzt.

!rr!rr_. schrieb:

Da man in Forth gerne jede erkennbare Code-Redundanz in neu definierte Wörter auslagert, sind Forth-Programme dazu oft noch äußerst kurz.

Jupp.
Aber eigentlich sehe ich Forth als eine saugeile Zwischensprache, die ein Forth-Prozessor in Hardware abarbeitet und Ausgabe eines zum Beispiel C++-Programms ist. Zur Zeit muß der C++-Programmierer recht assembler-affin sein, um sauschnellen Code zu bauen, der wegen viel time-space-tradoff bloatig wird. Mit Forth statt herkömmlichem asm als Zielsprache hätte man vielleicht Fixkosten von 5% dazu, aber ganze Betriebssysteme würden auf eine Diskette passen.
Naja, das will keiner. Prozessorbauer jagen ihre Konkurrenz lieber mit mehr und mehr Transistoren, weil die BS-Bauer nicht zeitnah ihr BS umbasteln könnten. Abermillionen closed Treiberzeilen von Fremdanbietern.
Die 5% haut der Prozessorbauer locker wieder raus, weil er viel weniger Transistoren braucht. Naja, außer für Spiele, wo für die 3d-Grafik exorbitante Tabellenwerke für Fließkomma-Arithmetik in Hardware gegossen werden. Hmmm, die Zocker hätten wenig Interesse daran. Aber genau die bestimmen, was gekauft und damit produziert wird. Schade.

volkard

_-- schrieb:

und schrieb:

dsffdsdf schrieb:

Kann ich davon ausgehen, dass C und C++ wirklich die schnellsten sind?

du kannst davon ausgehen, dass man auch dmit lahme SW schreiben kann.

lieber ne sprache welche bei programmierfehlern langsam wird, als eine die einfach nicht schneller geht. sonst fühlst dich wie in ner lahmen kiste ne steigung hoch fahrend auf dem sitz wippend/gaspedal pumpend in der hoffnung das ding geht doch iwie schneller

Umgekehrt.
Ich fuhr mal einen Smart...
Uih, war das ätzend. Er hatte Leistung!
Bergauf habe ich mit 130 alle anderen Kleinwagen abgehängt. Aber naja, so ein Überholvorgang 130 vs 110 muß von langer Hand geplant werden, um nicht der Arsch zu sein, der mit 130 auf der linken Spur tausend andere aufhält.
Bergab aber hat die Sau auch bei 130 abgeriegelt! Da kann ich nichtmal einen 96-er Laster überholen, weil alle normalen Kleinwagen (mit viel weniger Leistung(!)) mit 160 den Hang herabstürzen.
Also absolut nix für nette Fahrer wie mich. Bergauf bin ich ein Hindernis, bergab bin ich ein Hindernis.

Da fahre ich lieber eine Fiat mit viel weniger Leistung, der bergab schnell ist und bergauf sich in die Laster-Kolonne einreiht.

In Java fühle ich mich wie im Smart, "wie in ner lahmen kiste ne steigung *runter* fahrend auf dem sitz wippend/gaspedal pumpend in der hoffnung das ding geht doch iwie schneller". In C++ kann ich berab düsen wie sau. Also wenn das Problem in C/asm schnell wäre, ist es in C++ auch schnell. Bergauf ist halt die Mathematik/Schwerkraft gegen mich. Nehme ich vergleichbare Motoren, ist der Fiat natürlich bergauf auch nicht langsamer als der Smart.

wenn man mal richtige Rennen fährt und nicht nur Hobby-Überholrollen (language shootouts), ist es egal, ob dein Auto schnell bergab rollt. Dann kommt es darauf an, ob man fahren kann. Und C++ fährt für die meisten zu schnell und sie landen im Graben. Oder sie kommen mit der Handschaltung nicht klar und fahren immer nur im ersten Gang. Oder sie fahren weitab von der Ideallinie, was die meisten machen, egal mit welcher Sprache.

knivil

_-- schrieb:

lieber ne sprache welche bei programmierfehlern langsam wird, als eine die einfach nicht schneller geht. sonst fühlst dich wie in ner lahmen kiste ne steigung hoch fahrend auf dem sitz wippend/gaspedal pumpend in der hoffnung das ding geht doch iwie schneller

Dieses Bild/Vergleich verstehe ich nicht.

knivil schrieb:

_-- schrieb:

lieber ne sprache welche bei programmierfehlern langsam wird, als eine die einfach nicht schneller geht. sonst fühlst dich wie in ner lahmen kiste ne steigung hoch fahrend auf dem sitz wippend/gaspedal pumpend in der hoffnung das ding geht doch iwie schneller

Dieses Bild/Vergleich verstehe ich nicht.

Je öfter man es liest, desto weniger Sinn ergibts.

wie soll man auch etwas verstehen, was man nicht kennt? evtl. fahrt ihr schnelle autos oder habt noch nie in einer lahmen sprache (z.b. js/php) entwickelt

__-- schrieb:

wie soll man auch etwas verstehen, was man nicht kennt? evtl. fahrt ihr schnelle autos oder habt noch nie in einer lahmen sprache (z.b. js/php) entwickelt

Das hat damit nichts zu tun. Dein Satz ist einfach unlogisch.

für mich ist der mehr als logisch! sozusagen die krönung der logisch geschalteten sätze :p

volkard schrieb:

Mit Forth statt herkömmlichem asm als Zielsprache hätte man vielleicht Fixkosten von 5% dazu, aber ganze Betriebssysteme würden auf eine Diskette passen.

und in 8 GB RAM passen manche Forth-SYsteme Millionen Mal rein. Man könnte im RAM eines gewöhnlichen PC 1-2 Mio. Instanzen eines minimalen Forth-Systems im Multitasking laufen lassen ohne auf die Platte zuzugreifen. Ein ziemlich schneller Server.

Was sind eigentlich heutzutage noch die großen Nachteile von realen Stackmaschinen? Der hauptsächliche Nachteil war doch meines Wissens das ständige Push und Pop zwischen Stack und Speicher, das eine hohe Datenbandbreite erforderte. Aber das gilt doch für x86 beispielsweise auch, da ein ausreichend großer Hardwarestack doch sicherlich mehr Informationen halten kann als 2 oder 4 GP-Register. Ich kann mir gut vorstellen, dass man einen Stack sehr gut Cachen könnte, so wie man dieses Problem bei x86 ja auch umgeht. Könnte man nicht sogar den Stack nach oben erweitern und zukünftig benötigte Daten dort im Voraus ablegen?

Ein typischer RISC-Prozessor besitzt drei Parameter in Form von Registernummern, eine Stackmaschine besitzt höchstens einen für die Push/Pop-Kommandos. Dadurch könnte man doch auch beispielsweise bei einer 64 bit-Maschine und 10 bit Befehlssatz 6 Befehle auf einmal laden. Der Code wäre Kompakter und der Datenverkehr verringert.

Gibt es einen technischen Grund, warum Stackmaschinen so selten eingesetzt werden?

Forß schrieb:

Was sind eigentlich heutzutage noch die großen Nachteile von realen Stackmaschinen? Der hauptsächliche Nachteil war doch meines Wissens das ständige Push und Pop zwischen Stack und Speicher, das eine hohe Datenbandbreite erforderte. Aber das gilt doch für x86 beispielsweise auch, da ein ausreichend großer Hardwarestack doch sicherlich mehr Informationen halten kann als 2 oder 4 GP-Register. Ich kann mir gut vorstellen, dass man einen Stack sehr gut Cachen könnte, so wie man dieses Problem bei x86 ja auch umgeht. Könnte man nicht sogar den Stack nach oben erweitern und zukünftig benötigte Daten dort im Voraus ablegen?

Ein typischer RISC-Prozessor besitzt drei Parameter in Form von Registernummern, eine Stackmaschine besitzt höchstens einen für die Push/Pop-Kommandos. Dadurch könnte man doch auch beispielsweise bei einer 64 bit-Maschine und 10 bit Befehlssatz 6 Befehle auf einmal laden. Der Code wäre Kompakter und der Datenverkehr verringert.

Gibt es einen technischen Grund, warum Stackmaschinen so selten eingesetzt werden?

Google sagt, dass Stickmaschinen besser sind.