Warum schneidet in diesem Benchmark C schneller ab als C++?






  • Mod

    Guck doch in den Code!



  • Das Einzige, was mir auf die Schnelle auff├Ąllt, ist, dass im C-Code kein dynamisches Array verwendet wird. In http://benchmarksgame.alioth.debian.org/u64q/program.php?test=mandelbrot&lang=gcc&id=6wi wird das aber gemacht, und der ist auch noch deutlich schneller als das C++-Programm.


  • Mod

    Dann musst du mal profilen, wo der Unterschied liegt. Da du den Source hast und sogar alle Compilereinstellungen genau angegeben sind, sollte das nicht so schwer sein.



  • Die C Variante ist grausam codiert, sowohl rein codierungstechnisch wie auch performanzm├Ą├čig laienhaft, man sollte sich eher fragen warum C nur so viel schneller als C++ oder gar Java ist.


  • Mod

    Die meisten Programme scheinen von einer kleinen Kerngruppe zu stammen. Das hei├čt, die Ergebnisse sind vermutlich nicht repr├Ąsentativ f├╝r das was bei bester Kenntnis aller Techniken m├Âglich w├Ąre, sondern daf├╝r, was sich irgendein kleines Gr├╝ppchen vor ein paar Jahren mal ausgedacht hat.



  • Ja das trifft wohl den Kern.
    Dass sie auch noch OMP mit ins Spiel bringen, was f├╝r sprach├╝bergreifende Vergleichszwecke immer destruktiv ist, zeugt ebenso von begrenztem Horizont.



  • sprache vs sprache endet oft in implementiertung vs implementierung und das einzige was man daraus schlussfolgern kann ist die faehigkeit des implementators.



  • rapso schrieb:

    sprache vs sprache endet oft in implementiertung vs implementierung und das einzige was man daraus schlussfolgern kann ist die faehigkeit des implementators.

    Das.

    Da man in C++ quasi genau den gleichen Code schreiben kann wie in C (mit wenigen Ausnahmen die bzgl. Performance keinen oder nur einen unwesentlichen Unterschied machen), wird C nie wirklich schnellereren Code produzieren. Oft geht es um die verwendeten Bibliotheken oder Idiome.

    Wann lernen die Leute endlich, das C++ fuer praktisch alle Zwecke monoton maechtiger ist?



  • Kann man bei dem genannten Test auch irgendwie sein eigenes Programm hochladen? Ich denke, die 5s des C++ k├Ânnte man mit ein paar Optimierungen noch verbessern.

    Interessant w├Ąre z.B., wie teuer der operator [] von vector ist im Gegensatz zu reiner Zeigearithmetik. Das w├╝rde ich als erstes mal probieren. Ich erwarte mir keine Wunder, aber vielleicht bringt es ein bisschen was.


  • Mod

    tgttttggt schrieb:

    Kann man bei dem genannten Test auch irgendwie sein eigenes Programm hochladen? Ich denke, die 5s des C++ k├Ânnte man mit ein paar Optimierungen noch verbessern.

    Ja.

    Interessant w├Ąre z.B., wie teuer der operator [] von vector ist im Gegensatz zu reiner Zeigearithmetik. Das w├╝rde ich als erstes mal probieren. Ich erwarte mir keine Wunder, aber vielleicht bringt es ein bisschen was.

    Das w├Ąre schon eine ganz sch├Ân schlechte Implementierung, die operator[] nicht als return *(begin + index) implementiert.

    PS: Der GCC implementiert den Operator genau wie gesagt.
    Falls ich mal sfdfds glaube und sonst wirklich alles gleich ist, vermute ich den Unterschied eher in schlechtem Einsatz von OpenMP.



  • Also Optimierungen sch├Ân und gut, aber ich finde, ich benutze eine Sprache (z.B. C++) weil ich damit eher sch├Âneren und somit verst├Ąndlichen Code schreiben will. Deshalb benutze ich dann kein C oder Assembler.

    Wenn also Code bei diesen Benchmarks hoch geladen wird, dann will ich ehrlich gesagt keinen tot optimierten unverst├Ąndlichen Code lesen. Sondern den Code wie es die Sprache vorgesehen hat.

    Das gilt auch f├╝r C-Code: wenn der Assember-Schnippsel hat, ist es kein C-Code mehr. Tut mir leid. Dann ist das Fake!


  • Mod

    Artchi schrieb:

    Also Optimierungen sch├Ân und gut, aber ich finde, ich benutze eine Sprache (z.B. C++) weil ich damit eher sch├Âneren und somit verst├Ąndlichen Code schreiben will. Deshalb benutze ich dann kein C oder Assembler.

    Wenn also Code bei diesen Benchmarks hoch geladen wird, dann will ich ehrlich gesagt keinen tot optimierten unverst├Ąndlichen Code lesen. Sondern den Code wie es die Sprache vorgesehen hat.

    Das gilt auch f├╝r C-Code: wenn der Assember-Schnippsel hat, ist es kein C-Code mehr. Tut mir leid. Dann ist das Fake!

    Man kann nat├╝rlich umgekehrt sagen, dass es zeigt, wie einfach oder schwer (oder ├╝berhaupt m├Âglich) es ist, Code in einer gewissen Sprache zu optimieren. Man sieht beispielsweise, dass die Sprachen mit guter Multithreadingunterst├╝tzung (sei es nativ oder per leicht verf├╝gbarer Bibliothek) einen wesentlichen Vorteil haben. Ist halt die Frage, was man genau messen will. Das Ziel ist hier wohl, zu messen, was das bestm├Âgliche Programm f├╝r diese Sprache ist, das noch jemand freiwillig zu entwickeln bereit ist. Das ist ein anders Ziel als deines.



  • Nat├╝rlich kann am Ende jeder seinen Benchmark so auslegen, wie er es haben will (unverst├Ąndlicher Code, daf├╝r maximale Geschwindigkeit). Aber wie weit darf man das treiben? D├╝rfte jemand eine DLL in C schreiben, und diese dann von Java aus per JNI ansprechen, um mit Java den zweiten Platz zu belegen? ­čśâ


  • Mod

    Artchi schrieb:

    Nat├╝rlich kann am Ende jeder seinen Benchmark so auslegen, wie er es haben will (unverst├Ąndlicher Code, daf├╝r maximale Geschwindigkeit). Aber wie weit darf man das treiben? D├╝rfte jemand eine DLL in C schreiben, und diese dann von Java aus per JNI ansprechen, um mit Java den zweiten Platz zu belegen? ­čśâ

    Ja. Aber der Fakt, dass es niemand macht, zeigt, dass dies unrealistisch aufw├Ąndig ist ­čÖé

    Wohingegen es durchaus vertretbar ist ein paar OpenMP-Direktiven in C einzubauen.



  • Arcoth schrieb:

    Wann lernen die Leute endlich, das C++ fuer praktisch alle Zwecke monoton maechtiger ist?

    Oder nehmen lieber gleich eine gut optimierende Hochsprace wie Lisp oder Haskell oder Ruby oder wenigstens JavaScript, und entwickeln top-down, und machen nur die meistens sehr wenigen Codestellen die wirklich Performancekritisch sind in C und binden sie dann per FFI ein, und freuen sich dass sie schneller fertig sind, keine Segfaults haben, und kein Kopfzerbrechen ├╝ber endlose Compiler-Fehlermeldungen :3



  • Ramelucke schrieb:

    Arcoth schrieb:

    Wann lernen die Leute endlich, das C++ fuer praktisch alle Zwecke monoton maechtiger ist?

    Oder nehmen lieber gleich eine gut optimierende Hochsprace wie Lisp oder Haskell oder Ruby oder wenigstens JavaScript, und entwickeln top-down, und machen nur die meistens sehr wenigen Codestellen die wirklich Performancekritisch sind in C und binden sie dann per FFI ein, und freuen sich dass sie schneller fertig sind, keine Segfaults haben, und kein Kopfzerbrechen ├╝ber endlose Compiler-Fehlermeldungen :3

    Was ist mit Julia? https://www.heise.de/newsticker/meldung/Programmiersprache-Julia-profiliert-sich-beim-High-Performance-Computing-3518621.html



  • Julia klingt so als k├Ânnte was draus werden. Aber das hat man von Rust auch geglaubt. Warten wirs ab. :3



  • Ramelucke schrieb:

    Arcoth schrieb:

    Wann lernen die Leute endlich, das C++ fuer praktisch alle Zwecke monoton maechtiger ist?

    Oder nehmen lieber gleich eine gut optimierende Hochsprace wie Lisp oder Haskell oder Ruby oder wenigstens JavaScript, und entwickeln top-down, und machen nur die meistens sehr wenigen Codestellen die wirklich Performancekritisch sind in C und binden sie dann per FFI ein, und freuen sich dass sie schneller fertig sind, keine Segfaults haben, und kein Kopfzerbrechen ├╝ber endlose Compiler-Fehlermeldungen :3

    Nein, das ist eine sehr gute Idee. Ich habe ja auch von C++ vs C gesprochen, aber in tatsaechlichen Projekten koennen unkritische Stellen natuerlich funktional programmiert werden. Ich bevorzuge jedoch SML.


Log in to reply