Rust hat nun C++ im Benchmark Game geschlagen



  • Nochmal: C++ hatte hier deutlich mehr Zeit

    - performante Libs zu entwickeln
    - Compiler-Optimierungen zu entwickeln
    - Beim Benchmark-Game zu tunen

    Die Implementierungen sind zum Teil ziemlich ähnlich. Teilweise sieht du Anmerkungen wie "Java port from XXX" o. ä.

    Der Benchmark Game ist auch ein Test des Ökosystems, d. h.:
    - Compiler
    . Standard-Libs
    - Third Party Libs

    Du kannst bei diesem Game nicht beliebig tricksen. Bspw. darfst du für diesen Benchmark nicht extra eine HashMap implementieren, die für dieses Game ausgelegt ist. Es müssen entweder Standard-Libs sein oder üblich Third Party Libs, die breit verwendet werden.



  • Rust schrieb:

    Nochmal: C++ hatte hier deutlich mehr Zeit

    Der Rust-Compiler wurde natürlich ohne Erfahrungen und über Jahrzehnte gewonnene Erkenntnisse entwickelt.



  • SLx64 schrieb:

    Rust schrieb:

    Nochmal: C++ hatte hier deutlich mehr Zeit

    Der Rust-Compiler wurde natürlich ohne Erfahrungen und über Jahrzehnte gewonnene Erkenntnisse entwickelt.

    Der Backend-Compiler ist zugegebenermaßen llvm, aber dasselbe Backend führt nicht zwingend zur selben Performance.


  • Mod

    Der Rust-Code ist vom 3. März. Was du also vor allem misst, ist, dass letzte Woche jemand einen Rust-Code geschrieben hat, der C++-Code schlägt, für den seit 2013 niemand eine Neuerung eingebracht hat. Vermutlich aus Desinteresse, denn es gab bisher niemanden zu schlagen. Gib ihm ein paar Monate Zeit. Wenn es bis dann niemand schafft, einen besseren C++-Code zu schreiben, dann ist das berichtenswert.
    Es gibt übrigens auch neuen C-Code vom Januar/Februar, der nochmals schneller ist als der Rust Code. Es gab also allem Anschein nach einen Durchbruch darin, das Problem performant zu programmieren und nun ziehen andere Implementierungen nach. Ein Rust-Programmierer war dabei wohl schneller als C++-Programmierer.



  • Die Tendenz hat sich ja mit der Zeit für C/C++ nicht verbessert, sondern verschlechtert. Aber gut: Ich werde in 3 - 6 Monaten hier nochmals posten. – Bis dann. 😉


  • Mod

    Rust schrieb:

    Die Tendenz hat sich ja mit der Zeit für C/C++ nicht verbessert, sondern verschlechtert.

    Natürlich wird das Verhältnis immer schlechter. C und C++ werden zu einem gegebenen Programm optimalen oder nahezu optimalen Maschinencode erzeugen. Da gibt es einfach fast keine Möglichkeit mehr der Verbesserung, außer durch ein besseres Programm an sich. Daher können alle anderen nur aufholen.



  • Der Speicherverbrauch von den Rust-Programmen sieht aber noch nicht so gut aus wie bei C++ - braucht Rust tendenziell mehr Speicher? Wäre ein Nachteil im embedded Bereich



  • Gast3 schrieb:

    Der Speicherverbrauch von den Rust-Programmen sieht aber noch nicht so gut aus wie bei C++ - braucht Rust tendenziell mehr Speicher? Wäre ein Nachteil im embedded Bereich

    Liegt glaube ich da dran, dass Rust standardmäßig jemalloc verwendet und der ist austauschbar.



  • SeppJ schrieb:

    Rust schrieb:

    Die Tendenz hat sich ja mit der Zeit für C/C++ nicht verbessert, sondern verschlechtert.

    Natürlich wird das Verhältnis immer schlechter. C und C++ werden zu einem gegebenen Programm optimalen oder nahezu optimalen Maschinencode erzeugen. Da gibt es einfach fast keine Möglichkeit mehr der Verbesserung, außer durch ein besseres Programm an sich. Daher können alle anderen nur aufholen.

    Man kann da wirklich viel darüber diskutieren, z. B. darüber, dass Rust dem Backend-Compiler mehr Garantien geben kann und dieser dadurch aggressiver optimieren kann. Aliasing ist so ein Beispiel. Bei C99 kann man das manuell angeben, aber Rust macht das mit Sicherheitsgarantien schon automatisch. Gibt sicherlich noch andere Bereiche.
    Aber ich möchte hier ehrlich gesagt nicht alleine gegen Windmühlen ankämpfen. Das Ergebnis wird letztendlich den Beweis liefern und selbst dann werden noch einige sagen "Der Benchmark ist nichtssagend"...
    Wie gesagt: Ich komme in einigen Monaten nochmal darauf zurück.



  • Wie so oft: Das ist kein Sprachen oder Compilervergleich, sondern ein Implementierungsvergleich, da diese voneinander abweichen. z.B. Mandelbrot

    self.advance(4);
            for _ in 0..MAX_ITER / 5 - 1 {
                if self.all_diverged() {
                    return 0;
                }
                self.advance(5);
            }
            self.to_byte()
    
    Byte bits = 0xFF;
                for (int i = 0; bits && i < max_iterations; ++i)
                {
                    Byte bit_k = 0x80;
                    for (int k = 0; k < 8; ++k)
                    {
    ...
    

    Welche Aussage soll der Vergleich bringen? Da kann jemand auch ein Mandelbrot vorberechnen und als array ins binary backen und beweist dass BASIC am schnellsten ist.



  • Wieso nur, wieso finden Leute Balkenmarkierungen so wichtig und aussagekräftig? Lasst den Rustlern doch den Triumph, hier zu siegen, sie haben ihn verdient.

    Rust sieht nach einer Chance aus, endlich ettliche Altlasten die man ständig mit C++ rumschleppen muss abzulegen, ohne gleich eine ganze komplexe Runtime mit eigener komplexer Speicherverwaltung und eigenem JIT-Compiler herumtragen zu müssen.

    Ich bezweifle trotzdem, dass Rust sich durchsetzen wird, weil es den ganzen Javabots zu kompliziert sein wird, während die ganzen HPC-Leute lachen und sich zurück zu icc wenden werden. Deshalb sind ja auch Java und C weit oben im vorhin genannten TIOBE Index (dessen Aussagekraft aber auch eher zweifelhaft ist).

    Also: Keine Sorge, ihr werdet in absehbarer Zeit nichts neues lernen müssen, was nicht vorher von Sankt Stroustrup gesegnet wurde.



  • Es ist nur peinlich, unabhängig davon wer gewinnt. Manche Implementierungen verwenden SSE, manche bessere Algorithmen, manche boost threads, andere wiederrum OpenMP. Bei soeinem Vorgehen kannst du beweisen, dass C++ besser ist als C++.



  • Triumphwagen schrieb:

    Es ist nur peinlich, unabhängig davon wer gewinnt. Manche Implementierungen verwenden SSE, manche bessere Algorithmen, manche boost threads, andere wiederrum OpenMP. Bei soeinem Vorgehen kannst du beweisen, dass C++ besser ist als C++.

    Und jede Sprache hat mehrere Implementierungen und die Besten werden miteinander verglichen. Ist das jetzt unfair? Ich denke nicht.
    Wenn man Performancevergleiche machen möchte, braucht es irgendeinen Ansatz.



  • Es geht hier nur im die Sinnhaftigkeit von den Benchmarks (erstmal egal welche Sprache) - Rust könnte ernsthaft nah an C/C++ kommen - was bisher keiner Sprache so gelungen ist



  • Alle Jahr wieder kommt eine Sprache die der Nachfolger von C++ sein will. Das wurde von Java genau so behauptet wie von C#, D, usw. Alle versuchen zu beweisen, dass sie schneller sind, was immer sehr zweifelhaft ist. Java war nur interpretiert, aber es gab Benchmarks, wo unmengen von Speicher verbraten wurde (pass by Value in c++) und dann war Java schneller. MS hat den Beispiel-Shop von Java genommen, der absolut nicht schnell sein sollte, und bewiesen dass C# schneller als unoptimiertes Java ist. Es gab auch solche Benchmarks gegen C++, aber weniger peinlich. D hatte auch zweifelhafte Spezialfälle gezeigt, wo es schneller war.

    Zur Zeit hat wohl Swift die besten Karten, sowohl was Verbreitung, als auch was Geschwindigkeit angeht, weil.... Apple.
    1. Es ist schon vor Objective-C bei neugeschriebenen Anwendungen.
    2. Es nutzt LLVM gut aus, ist beides von Apple.
    3. Bisher hat Apple keine peinlichen Benchmarks gemacht, wozu denn auch?


  • Mod

    Swifty schrieb:

    Alle Jahr wieder kommt eine Sprache die der Nachfolger von C++ sein will. Das wurde von Java genau so behauptet wie von C#, D, usw. Alle versuchen zu beweisen, dass sie schneller sind, was immer sehr zweifelhaft ist. Java war nur interpretiert, aber es gab Benchmarks, wo unmengen von Speicher verbraten wurde (pass by Value in c++) und dann war Java schneller. MS hat den Beispiel-Shop von Java genommen, der absolut nicht schnell sein sollte, und bewiesen dass C# schneller als unoptimiertes Java ist. Es gab auch solche Benchmarks gegen C++, aber weniger peinlich. D hatte auch zweifelhafte Spezialfälle gezeigt, wo es schneller war.

    Die meisten davon hatten das Problem, dass sie Probleme schlecht lösten, die niemand ernsthaft hatte. Wer zum Beispiel denkt, dass C++ dringend ein Garbage Collector fehlt, der hat nie richtiges C++ gesehen, sondern nur C mit cout.



  • Swifty schrieb:

    Alle Jahr wieder kommt eine Sprache die der Nachfolger von C++ sein will. Das wurde von Java genau so behauptet wie von C#, D, usw. Alle versuchen zu beweisen, dass sie schneller sind, was immer sehr zweifelhaft ist. Java war nur interpretiert, aber es gab Benchmarks, wo unmengen von Speicher verbraten wurde (pass by Value in c++) und dann war Java schneller. MS hat den Beispiel-Shop von Java genommen, der absolut nicht schnell sein sollte, und bewiesen dass C# schneller als unoptimiertes Java ist. Es gab auch solche Benchmarks gegen C++, aber weniger peinlich. D hatte auch zweifelhafte Spezialfälle gezeigt, wo es schneller war.

    Dumm nur, dass Java bei dem Benchmark Game nicht sonderlich stark ist.
    Wenn du bei einem Code Schwächen siehst, kannst du ihn verbessern und einsenden.
    Das Bechmark Game ist deutlich unvoreingenommener und fairer als irgendwelche Benchmarks von Herstellern und Zeitschriften.

    Zur Zeit hat wohl Swift die besten Karten, sowohl was Verbreitung, als auch was Geschwindigkeit angeht, weil.... Apple.
    1. Es ist schon vor Objective-C bei neugeschriebenen Anwendungen.
    2. Es nutzt LLVM gut aus, ist beides von Apple.
    3. Bisher hat Apple keine peinlichen Benchmarks gemacht, wozu denn auch?

    Rust nutzt ebenfalls LLVM und scheinbar deutlich effizienter als Swift. Swift ist außerdem bis heute nicht wirklich Crossplattform. Es gibt kaum Toolchains außerhalb der Apple-Welt, sprich, Swift wird immer ein Apple-Produkt für die Apple-Plattform bleiben.
    Rust scheint alle möglichen von Entwicklern anzuziehen für das es ursprünglich gar nicht gedacht war. Z. B. auch Webentwickler:

    https://rocket.rs/

    PS: Apple hat sehr wohl "peinliche" Benchmarks gemacht. Nämlich mal immer wieder bei Key Notes.



  • Swifty schrieb:

    Alle Jahr wieder kommt eine Sprache die der Nachfolger von C++ sein will. Das wurde von Java genau so behauptet wie von C#, D, usw.

    Naja, man könnte jetzt darüber streiten, ob das Java nicht sogar ziemlich gut gelungen ist, wenn man mal die Verbreitung (inb4 TIOBE) ansieht. Aber das ist ein Punkt der bei Rust eben durchaus eine Chance wäre: Es ist eben nicht ein schlechter C++-Klon. Sie versuchen wenigstens mal, etwas fundamental anders zu machen. Ob das klappt, wird sich zeigen, ich habe meine Zweifel.

    SeppJ schrieb:

    Die meisten davon hatten das Problem, dass sie Probleme schlecht lösten, die niemand ernsthaft hatte. Wer zum Beispiel denkt, dass C++ dringend ein Garbage Collector fehlt, der hat nie richtiges C++ gesehen, sondern nur C mit cout.

    Die Beliebtheit von Sprachen mit vollautomatischer Speicherverwaltung spricht schon irgendwie dafür, dass das ein recht nützliches Feature ist, oder zumindest als solches wahrgenommen wird. Was du als "richtiges" C++ bezeichnest ist nicht klar. Ich nehme mal an, du siehst die Schönheit des Zusammenspiels vieler Komponenten, die eigentlich die meisten (oder gar alle?) Probleme elegant lösen würden, wenn doch nur der Rest der Welt sich die Zeit nähme, sie zu verstehen, statt sie schlechter neu zu erfinden. Nicht wahr?

    Tja, willkommen in meiner Welt



  • Java ist halt auf einem ganz anderen Level "der Nachfolger von C++".
    Eine VM bietet halt Tools wie aspektorientierte Programmierung und Reflection etc, man kann eigene ClassLoader schreiben, dies das jenes.

    Alles Dinge, bei denen es garantiert nicht um Performance geht. Wenn man einen Applicationserver betreibt, dann wird man garantiert nicht eine komplizierte C++-Entwicklung bei Performanceproblemen nehmen sondern einfach den Cluster vergrößern. Ein vernünftiger Server kostet weitaus weniger als ein lowend C++-Programmierer im Monat.

    Das gleiche bei Applikationen, bei denen 99% der Laufzeit Datenbank-Shit ist. Bringt nichts, den Käse in C++ neu zu schreiben, da würde es auch Python tun.
    Wobei bei den meisten Applikationen die pure Algorithmik das Problem ist, ein

    List<Foo> list = new LinkedList(...);
    for(int i = 0; i < list.size(); ++i) {
        doSomething(list.get(i));
    }
    

    ist in jeder Programmiersprache arschlangsam und meistens reicht es, soetwas zu eliminieren.

    Der Bereich, in dem (lowlevel) Performance so richtig relevant ist, ist ziemlich klein und da werden aus Prinzip C/C++ verwendet, alleine schon weil das komplette Ökosystem darauf ausgerichtet ist.




Anmelden zum Antworten