Rust hat nun C++ im Benchmark Game geschlagen

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.

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~~

Ethon

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.

https://www.heise.de/forum/heise-Developer/News-Kommentare/Programmiersprachen-Rust-stellt-Produktivitaet-ins-Zentrum/Rust-Produktivitaet/posting-29907675/show/

Ich suche Rust-Tutorials. Gefunden habe ich
https://doc.rust-lang.org/book/
http://rustbyexample.com/
http://rust-lang.github.io/book/second-edition/index.html
Gibt es noch weitere gute Tutorials?

Biolunar

Rust ist cool schrieb:

Ich suche Rust-Tutorials. Gefunden habe ich
https://doc.rust-lang.org/book/
http://rustbyexample.com/
http://rust-lang.github.io/book/second-edition/index.html
Gibt es noch weitere gute Tutorials?

https://doc.rust-lang.org/nomicon/ ist noch zu empfehlen, sobald du das Book durch hast. Fang am besten mit der second edition an und lerne über die Themen, die dort noch nicht vollständig sind aus dem ersten Buch. Danach einen Blick in das Nomicon werfen.

nachtfeuer

Ethon schrieb:

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.

Ich möchte in diesem Zusammenhang nur ergänzen, dass (z.B.) im GHC (Haskell Compiler) relativ aktuelle und wissenschaftlich fundierte Paralleltechnik/eingebaut ist (so gut es eben geht).
(und gerade Lowlevel Parallel, also mit vielen vielen Prozessoren ist nicht zu empfehlen aber die Pentiums und andere sind mit ihrer eigenen internen Paralleltechnik (RISC, Caches, Pipelines usw.) in erster Linie (traditionell) C-optimiert).

Zee++ 0

Für mich wird eine Programmiersprache auch davon getragen:

- wie groß ist Community
- gute Fachliteratur
- gute IDE
- gute GUI und Standardbibliothek
- viele Libs
- einfach zu verstehen(gut C++ ist auch schwer)

Was ich damit sagen will. Allein dass eine Sprache gut designet und schnell ist macht sie nicht automatisch erfolgreich.

Rust ist interessant und die Entwicklung in den nächsten 10 Jahren kann man sich ruhig mal anschauen, aber einsetzen würde ich Rust privat noch nicht.

https://blog.rust-lang.org/2017/04/27/Rust-1.17.html Rust 1.17 is out now!