Was haltet ihr von Rust?



  • Mechanics schrieb:

    We are porting Reddit-flavored Markdown parser from our open sourced C implementation to Rust and need someone to lead this project. This project will impact millions of users and pages.

    Ich bin etwas überrascht. Die wollen jemanden fest anstellen, und das soll anscheinend auch nicht der einzige sein, der an dem Projekt arbeitet. Das ganze Projekt schaut für mich aber sehr überschaubar aus. Vielleicht gibts da intern noch viel mehr, als das was sie auf Github veröffentlich haben. Aber das Projekt auf Github find ich jetzt echt sehr überschaubar. Vor allem, wenn man das beim Portieren nicht von Hand schreiben, sondern einen Parsergenerator verwenden würde, sollte sich der Aufwand m.E. sehr in Grenzen halten.

    Parsen sollte tatsächlich nicht so schwierig sein. Markdown ist ziemlich simpel gehalten.
    Wie wird das Ergebnis des Parsers weiterverarbeitet, wird HTML generiert? Ist an der Stelle vielleicht mehr Aufwand zu betreiben? Keine Ahnung.
    Hab gesehen, dass die Stelle bei San Fran gesucht wird. Dort ist es ja auch recht wichtig, möglichst hip zu sein, und dafür eigenet sich Rust defintiv besser als C++ 😉



  • Haskell rulez schrieb:

    Wie kurz kann man das Haskell-Programm

    length $ words "$TEXT"
    

    zum Zählen der Wörter eines Textes in Rust machen? In C++ muss man dafür ja einiges schreiben ...

    text.split(" ").count()

    ist nicht viel länger in C++...



  • Mich wundert es jetzt nicht mehr, warum Binaries, deren Quellcode in Rust programmiert wurde langsamer sind, als Binaries, deren Quellcode in C++ geschrieben wurden.

    Das Problem scheint LLVM zu sein auf dem Rust aufbaut. (mir ist jedenfalls kein anderer Compiler für Rust bekannt)

    Hier gibt es bspw. einen Compilertest, bei dem werden zwar nur C++ Compiler verglichen, aber der Intel C++ und der GNU g++ Compiler sind durch die Bank schneller, als alle C++ Frontends für LLVM.
    https://colfaxresearch.com/compiler-comparison/#sec-3-1

    Jetzt stellt sich natürlich die Frage, welche Rolle das x64 Backend für LLVM spielt, aber das ist ja eigentlich das, welches den Maschinencode überhaupt erst erzeugt, weswegen ich davon ausgehe, dass das Performancenadelöhr überwiegend im Backend liegt.
    Rust kann somit gar nicht vergleichbar schnell sein, wenn man es mit C++ vergleicht und für C++ einen hochoptimierten Compiler wie eben den von Intel wählt.

    Wirklich vergleichbar wäre somit eigentlich nur Rust mit C++ Code der mit Clang, also LLVM, compiliert wurde.
    Sobald was anderes, wie bspw. GNU g++ im Spiel ist, hat Rust keine Chance mehr und das wird so lange bleiben, solange das Backend für LLVM nicht wesentlich besser wird.



  • Das stimmmt zwar, aber ob die Geschwindigkeitseinbuße in der Praxis wirklich nennenswert ist?
    LLVM wird ständig von einer großen Gemeinschaft weiterentwickelt, sodass immer wieder Optimierungen einfließen, von denen alle Sprache, welche auf LLVM aufsetzen, profitieren.
    Letztlich bietet LLVM – und damit auch Rust – den unschlagbaren Vorteil, einen Compiler für jede Plattform verfügbar zu haben und übergreifend kompilieren zu können, da nimmt man ein paar % weniger Geschwindigkeit gern in Kauf. Mit dem GCC ist soetwas nicht möglich.
    Da Rust im Gegensatz zu Java oder irgendwelchen Skriptsprachen keine Laufzeitumgebung benötigt, hat man ohnehin grundsätzlich mit einer enorm hohen Performanz zu tun.



  • Mich wundert es jetzt nicht mehr, warum Binaries, deren Quellcode in Rust programmiert wurde langsamer sind, als Binaries, deren Quellcode in C++ geschrieben wurden.

    Kompiler sind so komplexe gebilde das es sehr schwer ist globale Aussage zur Performanz zu machen - so wie du es hier machst, das ist irgendein Beispiel in den eben deren präferierter Kompiler besonders gut raus kommt, aus solchen Benchmarks kommen z.B. diese Idioten "der Intel macht immer den schnellesten Code" Aussagen die durch die Branche wabbern - und wie oft das gar nicht stimmt

    der Clang und GCC sind auf jeden Fall - neben dem CL von Microsoft die Platzhirsche auf der Welt

    Google hat erst letzte Woche für Windows die Kompilation vom Microsoft CL auf den Clang-Cl umgestellt (für knapp 3-4+ Mio Zeilen Code) - also alles schön auf LLVM Basis, meinst du die machen das ohne die Performanz genau zwischen den verwendeten Kompileren abzuwägen?

    deine Aussage klingt wie "guck der ist total schlecht" und das stimmt so absolut gar nicht

    Da Rust im Gegensatz zu Java oder irgendwelchen Skriptsprachen keine Laufzeitumgebung benötigt, hat man ohnehin grundsätzlich mit einer enorm hohen Performanz zu tun.

    computertrolls ruft aus der einen Ecke "der ist total langsam der Code" und du rufst aus der anderen "man hat ohnehin grundsätzlich mit einer enorm hohen Performanz zu tun" - wie wärs mit etwas weniger kraftvollen Sätzen die sich an der Realität orientieren 🙂



  • computertrolls schrieb:

    Sobald was anderes, wie bspw. GNU g++ im Spiel ist, hat Rust keine Chance mehr und das wird so lange bleiben, solange das Backend für LLVM nicht wesentlich besser wird.

    Wenn das wirklich so ist (was ich nicht sagen kann, da ich mit Rust keine Erfahrung hab), dann kann das nicht an LLVM liegen. Clang und g++ nehmen sich in Sachen Performance in der Regel nicht viel, in vielen Fällen generiert Clang schnelleren/besseren Code...

    Edit: achso, du meintest das LLVM Backend im Rust Compiler...



  • dot schrieb:

    dann kann das nicht an LLVM liegen. Clang und g++ nehmen sich in Sachen Performance in der Regel nicht viel, in vielen Fällen generiert Clang schnelleren/besseren Code...

    Schau dir mal den oben verlinkten Artikel an. Da wird nur die Performance von C++ verglichen und Clang ist da deutlich langsamer als g++.

    Edit: achso, du meintest das LLVM Backend im Rust Compiler...

    Meines Wissens nach ist das LLVM Backend für den LLVM Zwischencode.
    Für die Hochsprachen gibt es die LLVM Frontends, die meine ich aber nicht.



  • Gast3 schrieb:

    Kompiler sind so komplexe gebilde das es sehr schwer ist globale Aussage zur Performanz zu machen - so wie du es hier machst, das ist irgendein Beispiel in den eben deren präferierter Kompiler besonders gut raus kommt,

    Die haben keinen Compiler präferiert, sondern einfach alle getestet die bestimmte Kriterien (z.b. auch unter Linux verfügbar) erfüllen.
    Und die Tests sind 3 verschiedenen Codes mit einem ganz anderen Aufgabengebiet.

    Übrigens scheinen die Leute sich auszukennen, immerhin arbeiten sie im high-performance computing Bereich.

    aus solchen Benchmarks kommen z.B. diese Idioten "der Intel macht immer den schnellesten Code" Aussagen die durch die Branche wabbern - und wie oft das gar nicht stimmt

    Im obigen Artikel ist der Intel Compiler der, der die schnellsten Binaries erzeugt und das habe ich schon öfters in solchen Compiler-Vergleichen gesehen.
    Das ist also durchaus etwas dran.

    der Clang und GCC sind auf jeden Fall - neben dem CL von Microsoft die Platzhirsche auf der Welt

    Das bestreitet auch niemand. Dennoch ist Clang oder das damit zusammenhängende LLVM Backend, wie der Vergleich zeigt, langsamer.
    Dass es am LLVM Backend liegen könnte, dafür spricht die Tatsache, dass man gleich 3 C++ Compiler ausprobiert hat, die das LLVM Backend verwenden.
    Und die haben alle im Vergleich zum Intel oder GNU Compiler schlecht abgeschnitten.

    Google hat erst letzte Woche für Windows die Kompilation vom Microsoft CL auf den Clang-Cl umgestellt (für knapp 3-4+ Mio Zeilen Code) - also alles schön auf LLVM Basis, meinst du die machen das ohne die Performanz genau zwischen den verwendeten Kompileren abzuwägen?

    Das könnte auch daran liegen, weil man bei Google auch noch andere Projekte in gänzlich anderen Hochsprachen entwickelt und hier eine Toolvereinheitlichung administrative Vorzüge haben könnte.

    Wenn ich mich nicht irre, betraf das übrigens nur Chrome.
    Chrome läuft aber nicht auf der Hardware von Google, sondern auf der der Kunden.
    Es dürfte Google nicht so wichtig sein, wie der dort performant.

    Etwas anderes wäre es, wenn bspw. eine Software im high-performance computing Bereich, die bei Google für Google läuft, auf einen anderen Compiler umgestellt wird.
    Denn wenn da das Binary langsamer laufen würde, dann würde das Google bares Geld kosten.

    deine Aussage klingt wie "guck der ist total schlecht" und das stimmt so absolut gar nicht

    Nein, meine Aussage basiert auf einem empirischen Tests.
    Deine Aussage "das stimmt so absolut gar nicht" ist dagegen in der Tat nur eine Behauptung ohne Fundament.



  • computertrolls schrieb:

    dot schrieb:

    dann kann das nicht an LLVM liegen. Clang und g++ nehmen sich in Sachen Performance in der Regel nicht viel, in vielen Fällen generiert Clang schnelleren/besseren Code...

    Schau dir mal den oben verlinkten Artikel an. Da wird nur die Performance von C++ verglichen und Clang ist da deutlich langsamer als g++.

    Soweit ich das sehen kann, handelt es sich bei dem verlinkten Artikel lediglich um einen OpenMP Benchmark. Nicht gerade repräsentativ wenn du mich fragst... 😉

    Guckst du beispielsweise hier, schaut die Sache schon anders aus... 😉



  • dot schrieb:

    Guckst du beispielsweise hier, schaut die Sache schon anders aus... 😉

    Finde ich jetzt nicht.

    Ich habe mir die Ergebnisse jetzt mal ganz genau angesehen und nicht nur den Phoronix Text gelesen und aus den Ergebnissen kann man folgendes herauslesen:

    Da wo Clang gegen g++ mal gewinnt, liegt er nur ein bisschen vorne.
    Da wo er aber verliert und das passiert noch recht häufig, da liegt er teilweise sogar sehr weit zurück.

    Die Ergebnis zeigen mir, dass g++ momentan unterm Strich schneller ist und das teilweise sogar deutlich.

    Clang und LLVM werden natürlich stetig besser, keine Frage, die Entwicklung schreitet schließlich voran, aber momentan liegt der GNU Compiler noch vorne.

    Und solange das LLVM Backend, wie die 3 C++ Codebeispiele im vorherigen Benchmark, die von den drei LLVM C++ Frontends in den Zwischencode für das LLVM Backend compiliert wurden, zeigen, dürfte auch Rust noch hinten liegen, denn neben dem LLVM Frontend von Rust hängt die Geschwindigkeit der compilierten Binaries auch vom LLVM Backend ab.
    Ohne besseres LLVM Backend wird's also keine performanten Binaries geben, die mit Rust entwickelt wurden.
    Für C++ gibt's momentan also einfach noch die besseren Compiler.


Anmelden zum Antworten