Programming language shootout



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

    Wie aussagekräftig ist dieser Test? Kann ich davon ausgehen, dass C und C++ wirklich die schnellsten sind?



  • Und: Wie vergleichen sich g++ und Visual C++ und Intel C++?


  • Mod

    dsffdsdf schrieb:

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

    Im großen und ganzen ja. Die Sprachen haben sehr wenig Overhead, die Compiler sind sehr ausgereift. Fortran und Assembler könnten noch in der gleichen Liga spielen, wurden aber nicht getestet. Eventuell auch Java wenn man spezielle Benchmarks wählt bei denen der JIT glänzen kann. Aber im C und C++ sind in vielen Anwendungsszenarien unübertroffen schnell und zeigen in kaum einem Gebiet Performanceschwächen.

    dsffdsdf schrieb:

    Und: Wie vergleichen sich g++ und Visual C++ und Intel C++?

    Nicht sehr unterschidlich, Geschwindigkeitsunterschiede sind im niedrigen Prozentbereich. Je nach Programm ist das unterschiedlich, aber meiner Erfahrung nach kann man mit dem Intelcompiler eher schnellere Programme erzeugen als mit dem g++. Visual C++: Keine Ahnung, benutze ich nicht, konkuriert auch nicht wirklich mit den anderen beiden.



  • Imho liegt das Problem solcher Benchmarks vorallem darin, dass derartige Miniprogramme kaum Aussagekraft für das Verhalten komplexer Software haben.
    Die Algorithmen sind bereits hoch optimiert, was in der Praxis eher nicht der Fall sein dürfte.
    Die Ausdrucksstärke der Sprache spielt hier ebenso keine Rolle. Aber: Dinge, die ich in sehr abstrakten Sprachen wie - z.B. - Lisp, Prolog etc. sehr einfach beschreiben könnte, machen in C, C++ etc. komplexe Designs notwendig, bei denen Abstraktionsschicht auf Abstraktionsschicht gepackt wird. Fraglich, was am Ende schneller ist.
    Zudem wird hier nur die Performance einer konkreten Implementierung des Problems mit einer anderen verglichen. Wer sagt, dass man eine vermeintlich langsame Implementierung nicht noch verbessern könnte? C und C++ sind ja ein gutes Beispiel - inwiefern unterscheidet sich denn die C++ von der C-Variante? Durch zwanghaften Gebrauch von Klassen?
    Die Zeilenangaben bei diesen Vergleichen kann man sowieso igorieren, da teils absurde Formatierungen benutzt werden.

    Imho sagt dieser Benchmark nur etwas über die Performance bei sehr gut verstandenen Problemen aus. Wenn man aber nicht gerade einen Numbercruncher schreiben will, hilft er nur begrenzt weiter.



  • Rennwagen gegen Geländewagen, welches Auto ist schneller?



  • Die Geschwindigkeit eines Programms (wie könnte man die eigentlich definieren ?) ist
    nur 1 Aspekt. Habe ich genug Zeit und jemanden, der's bezahlt, kann ich das gnadenlos
    optimieren. Wenn nicht, dann halt nicht. Auch spielt dann eine Rolle, was mit dem
    Programm überhaupt gemacht wird: An ein GUI-Programm werden ander Ansprüche gestellt
    wie an eins, das nachts mal eine Stunde läuft.

    Ob Benchmarks da irgendwie helfen ?


  • Mod

    Scheppertreiber schrieb:

    Ob Benchmarks da irgendwie helfen ?

    Ja, natürlich 😕 . Ist ja nicht so, dass es nur Geschwindigkeitsbenchmarks geben würde. Hier ging es aber eindeutig um reine Geschwindigkeit und die wurde, soweit ich das sehe, auch gemessen. In den detaillierten Ergebnissen stehen aber auch andere Sachen, z.B. Größe des Sourcecodes gegen die Geschwindigkeit.



  • Ich mein ja nur 😉

    Ich habe dabei ("Shootout") immer so ein blödes Gefühl. Irgendwie ist das
    so wie ASU beim TÜV: Der Bordrechner erkennt den Prüfzyklus und ... 🕶



  • 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 😃



  • !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.



  • _-- 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.



  • _-- 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


Anmelden zum Antworten