Rust hat nun C++ im Benchmark Game geschlagen

Ich kann mich noch daran erinnern, als Rust nur in 2-3 Tests schneller war als C++, aber nun ist Rust in 6 von 10 Test schneller als C++ und diese Entwicklung wird wahrscheinlich so weitergehen! – Schon erstaunlich!

http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp

wie gut das wir alle wissen welche Relevanz synthetische Benchmarks haben
und im Hintergrund hört man dazu auch noch leise den Wind _TIOBE-Index säuseln

Ja, ich kenne die Kritik, aber deswegen werden hier auch 10 verschiedene Benchmarks vorgestellt und die Tatsache, dass C++ deutlich älter ist, lässt es nicht gerade gut aussehen. Die weitere Tatsache, dass in zwei von den vier Tests, wo C++ schneller ist, auf SIMD zurückgegriffen wird. SIMD wird von Rust momentan nur in den Nightly-Builds unterstützt. Die Tests werden jedoch mit dem Stable-Compiler gemacht, insofern sind diese Tests momentan nicht ganz fair und benachteiligen Rust.
Die Tests zeigen ganz klar Tendenzen auf und C++ hatte einen Vorsprung von einigen Jahrzehnten...

Wenn beiden Sprachen von ihrem Design her in der Lage sind auf gleichem Niveau "schnell" zu sein geht es um viel mehr Details als in diesen Beispielen gezeigt werden

d.h. ein Scriptsprache ohne JIT gegen C++ ist ein lustiges Beispiel - aber da
reicht schon Quicksort um das zu zeigen

wenn sich jetzt wieder mal ein guter C++ daran versucht kann es schon wieder ganz anders aussehen - und dann wieder ein Rustler usw.,usw.

Mit solchen Tests kann man nur Performanz-Unterschiede in externen Bibliotheken oder Strategien aufzeigen - alles andere ist nur für die Meiner-ist-länger-als-deiner-Programmiersprache-Gruppe

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.

SLx64

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.

SeppJ

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.

SeppJ

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.

rapso

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?

SeppJ

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.