Ist Rust schneller als C?

 (steveklabnik.com)
13 Punkte von GN⁺ 2026-01-15 | 9 Kommentare | Auf WhatsApp teilen
  • Der Leistungsvergleich zwischen Rust und C ist eine komplexe Frage, deren Antwort davon abhängt, wie die Annahme „alle Bedingungen sind gleich“ definiert wird
  • Bei Inline-Assembly können beide Sprachen denselben Assembly-Code erzeugen, daher gibt es keinen Geschwindigkeitsunterschied durch die Sprache selbst
  • Beim Speicherlayout von Structs kann Rust durch Neuanordnung von Feldern eine kleinere Größe erreichen, mit dem Attribut #[repr(C)] ist aber auch ein identisches Layout wie in C möglich
  • Durch Unterschiede bei Laufzeitprüfungen und dem Verhalten von Entwicklern können sich in realen Projekten Code-Struktur und Performance unterscheiden
  • Schlussendlich gibt es keinen Leistungsunterschied aufgrund inhärenter Sprachgrenzen; das Ergebnis hängt von Projekt- und Entwicklerfaktoren ab

Problemstellung und die Unschärfe der Prämissen

  • Ausgangspunkt ist die auf Reddit gestellte Frage: „Kann Rust unter gleichen Bedingungen schneller als C sein?“
  • Die Formulierung „alle Bedingungen sind gleich“ ist beim Vergleich von Sprachen selbst ein sehr schwer zu definierendes Konzept
  • Leistungsvergliche hängen nicht nur von Sprachunterschieden ab, sondern auch von Code-Form, Entwicklungsentscheidungen und Compiler-Optimierungen

Vergleich von Inline-Assembly

  • Rust unterstützt Inline-Assembly auf Sprachebene, C dagegen über Compiler-Erweiterungen
    • In beiden Sprachen lässt sich dasselbe Beispiel mit dem Befehl rdtsc schreiben
    • Der von rustc 1.87.0 und clang 20.1.0 erzeugte Assembly-Code ist vollständig identisch
  • Dieses Beispiel zeigt keinen Performance-Unterschied der Sprachen, belegt aber, dass Rust Low-Level-Kontrolle auf demselben Niveau wie C bieten kann

Unterschiede im Struct-Layout

  • Rust-Structs können die Speichernutzung durch Neuanordnung von Feldern optimieren
    • Im Beispiel ist das Rust-Struct 16 Byte groß, das entsprechende C-Struct 24 Byte
  • In C muss die Reihenfolge der Felder manuell geändert werden, um auf dieselbe Größe zu kommen
  • Mit dem Attribut #[repr(C)] lässt sich in Rust dasselbe Speicherlayout wie in C erzwingen

Soziale und entwicklerbezogene Faktoren

  • Dank der Sicherheitsprüfungen von Rust gibt es Fälle, in denen Entwickler aggressivere Optimierungen versuchen können
    • Im Stylo-Projekt von Mozilla scheiterten zwei Parallelisierungsversuche in C++, während die Umsetzung in Rust erfolgreich war
  • Selbst im selben Projekt können sich je nach Sprache und Erfahrung der Entwickler Performance und Stabilität des resultierenden Codes unterscheiden
  • Da sich das Ergebnis „derselben Aufgabe“ je nach Kenntnisstand von Einsteigern und Experten sowie je nach Sprachbeherrschung unterscheidet, sind einfache Vergleiche schwierig

Compile-Time- und Laufzeitprüfungen

  • Viele Sicherheitsprüfungen in Rust werden zur Compile-Time durchgeführt, einige bleiben jedoch Laufzeitprüfungen
    • Beim Zugriff auf array[0] führt Rust beispielsweise eine Bounds-Check-Prüfung durch, C nicht
    • Mit get_unchecked() kann man in Rust dasselbe Verhalten wie in C erhalten
  • Wenn der Compiler Sicherheit nachweisen kann, können beide Sprachen Prüfungen durch Optimierungen entfernen
  • Diese Unterschiede beeinflussen die Art, wie Code geschrieben wird, und können dadurch letztlich Performance-Unterschiede verursachen

Fazit

  • Selbst wenn man annimmt, dass C „die schnellste Sprache“ ist, gibt es keinen Grund, warum Rust nicht dasselbe Leistungsniveau erreichen könnte
  • Nicht inhärente Sprachgrenzen, sondern Projekteigenschaften, Entwicklerfähigkeiten, Zeitbeschränkungen und andere externe Variablen entscheiden über Leistungsunterschiede
  • Die Frage „Ist Rust schneller als C?“ ist daher eher eine Frage des Engineering-Kontexts als des Sprachvergleichs

Verwandte Beiträge

9 Kommentare

 
jokerized 2026-01-16

Im Embedded-Bereich wird sogar unter Berücksichtigung der Hardware-Cache-Line-Größe programmiert. Es dürfte letztlich darauf ankommen, wie weit ein Programmierer auf Sprachebene extreme Optimierungen treiben kann und wie gut Standardbibliothek und Compiler performen. Da beide ohnehin Low-Level-Unterstützung bieten, scheint der Unterschied bei einem geringen Overhead wohl minimal zu sein. Deshalb ist das meiner Meinung nach keine besonders sinnvolle Debatte. Wenn eine extreme Optimierung nötig ist, braucht es am Ende ohnehin menschliches Eingreifen. Compiler sind nämlich nicht so perfekt, wie man vielleicht denkt.
 
iolothebard 2026-01-15

Ich denke, Rust wird eher ein Ersatz für C++ als für C sein. C ist praktisch die einzige (vielleicht letzte) Sprache, bei der man den vom Compiler erzeugten Code abschätzen kann …
 
secret3056 2026-01-16

Zig ist auch nicht schlecht ... T_T
 
iolothebard 2026-01-15

Beim Schreiben ist es irgendwie zu einem KI-Zusammenfassungsstil geworden ;_;
 
galadbran 2026-01-16

Haben Sie das nicht absichtlich gemacht, hehe?
 
winmain 2026-01-15

Das hängt von den Fähigkeiten des Compilers ab.

Wenn man denselben Code assembliert, wird man es sehen.
 
jjw9512151 2026-01-15

Die ffmpeg-Leute scheinen wohl zu denken, dass Rust nicht unbedingt schneller als C ist, haha https://www.memorysafety.org/blog/rav1d-perf-bounty/
 
GN⁺ 2026-01-15
Hacker-News-Kommentare

  • Kurz gesagt: Die Maximalgeschwindigkeit ist fast gleich, aber bei echtem Code gibt es große Unterschiede
    Vor allem ist Multithreading ein großer Faktor. In Rust müssen alle globalen Variablen thread-sicher sein, egal ob Threads verwendet werden oder nicht, und der Borrow Checker beschränkt Speicherzugriffe darauf, entweder geteilt oder verändernd zu sein
    Dadurch ist das Schreiben von Multithreading-Code in Rust fast schon der Standard. In C ist schon das Erzeugen von Threads belastend, etwa wegen Plattformkompatibilität oder Debugging-Risiken

    • Ehrlich gesagt denke ich, dass dieser Unterschied vor allem an der Bequemlichkeit der Standardbibliothek liegt
      Threads in C zu bauen ist nicht schwer, aber umständlicher als Rusts std::thread::spawn(move || { ... });
      Mehr als die Speichersicherheit beeinflusst das Nebenläufigkeitsmodell der Sprache. Go lässt sich auch ohne Speichersicherheit mit go f() leicht parallelisieren
      Persönlich habe ich in Go häufiger Heisenbugs gesehen
    • Abgesehen vom Multithreading frage ich mich, ob Rusts Typsystem mehr Informationen liefert und dadurch mehr Raum für Optimierung schafft
    • Tatsächlich kann man auch in C mit einer Zeile #pragma omp for einfach parallelisieren
    • Ich bin immer noch verwirrt, warum man für Multithreading unter Linux TBB linken muss. Das sollte meiner Meinung nach standardmäßig enthalten sein
    • Wenn man wahllos Threads hinzufügt, sollte man auch Energieverbrauch und Race Conditions bedenken

  • Dank Rusts Traits lassen sich schnellere und flexiblere Abstraktionen bauen
    In C kann man das mit Makros oder Funktionszeigern nachahmen, aber in Rust kann der Aufrufer zwischen dynamischem Dispatch und statischem Dispatch wählen
    In Embedded-Umgebungen zerstören Funktionszeiger den Cache und kosten Leistung, während Rust-Traits Inlining-Optimierungen erlauben und daher deutlich effizienter sind

    • Ich mag auch ELF-Hacking, aber für Performance muss man Linker, ABI und Binärformate gut verstehen
      Egal ob Rust oder C, am Ende arbeitet man auf Byte-Ebene, und inzwischen sind auch Werkzeuge für Binary Patching besser geworden und leicht nutzbar
    • Natürlich kann man auch in Rust den Aufrufer zu dynamischem Dispatch zwingen, wenn man Box<dyn Trait> in der Funktionssignatur verwendet
      Mit impl Trait bleibt dem Aufrufer die Wahl
    • Wenn man allerdings viele Traits verwendet, steigt die Build-Zeit merklich. Je komplexer die Traits, desto langsamer die Kompilierung
    • Der C-artige Ansatz ist, Abstraktion ganz zu vermeiden

  • Persönlich sehe ich Rust, C und C++ fast als dieselbe Familie niedrigstufiger Sprachen, daher halte ich die Leistungsunterschiede für gering
    Rusts strenge Aliasing-Regeln sind vorteilhaft für Optimierungen, und UB (Undefined Behavior) in C/C++ existiert zugunsten der Performance
    Außerdem sind Generics in Rust und C++ viel mächtiger als in C; etwa ist template-basiertes Sortieren statt qsort() leichter inline zu optimieren

    • C++-Templates sind in ihrer Ausdrucksstärke immer noch stärker als Rust, aber der Abstand wird kleiner
    • Eigentlich ist das eher ein Problem des Designs der Standardbibliothek als der Sprache. Auch in C kann man selbst inline-fähige Sortierfunktionen bauen
    • Rusts Behandlung von Integer-Overflow folgt dem Standardverhalten der Plattform, daher können sich Ergebnisse je nach Optimierung unterscheiden
    • Eine Sprache ist nur ein Mittel zur Beschreibung von Verhalten; die tatsächliche Geschwindigkeit hängt vom Compiler und der Laufzeitumgebung ab
    • Die Leistungsunterschiede zwischen den drei Sprachen sind letztlich eine Frage von Effizienz im Verhältnis zum Aufwand. C ist schnell, aber teuer in der Entwicklung, Rust liegt irgendwo dazwischen

  • Ich halte solche Geschwindigkeitsdebatten zwischen Sprachen meist für sinnlos
    Mehr als die Sprache selbst bestimmt die Compiler-Implementierung die Leistung

    • Trotzdem hat das Sprachdesign großen Einfluss auf die Optimierbarkeit. Ein „hinreichend intelligenter Compiler“ ist noch immer eher ein Mythos

  • Rust, C und C++ sind alle niedrigstufige Sprachen, aber wichtig ist, was mit „schnell“ gemeint ist
    Geht es um die Höchstgeschwindigkeit von Code, den Experten optimiert haben, oder um die Wahrscheinlichkeit, dass durchschnittliche Entwickler innerhalb des Budgets schnellen Code schreiben? Das ist ein Unterschied

    • In der Praxis ist die Optimierungsfähigkeit des Compilers entscheidend. Rusts Speichersemanik ist reichhaltiger, sodass der Compiler mehr Informationen für Optimierungen erhält
      Mit manueller Optimierung verschwinden die Unterschiede zwischen den Sprachen jedoch fast vollständig
      Rust hat allerdings einen kleinen Vorteil darin, dass es eine Sprache ist, in der sich schneller Code leichter schreiben lässt
    • Die meisten Menschen verwenden die Definition „eine Sprache, in der durchschnittliche Entwickler schnellen Code schreiben können“
    • Sprachdesigner haben im Blick, „wie schnell typischer Code in dieser Sprache sein wird“, deshalb halte ich die Frage für sinnvoll

  • Ich dachte immer, Rusts Vorteile seien Multithreading und Stack-Allokation
    Dank des Ownership-Modells kann man mehr auf den Stack legen als in C/C++, was malloc/free-Overhead reduziert

    • Stimmt, aber in dieser Diskussion ging es weniger um solche konkreten Unterschiede als um einen konzeptionellen Vergleich aus Sicht des Sprachdesigns
      Bei solchen Themen wird oft emotional gestritten, deshalb wollte ich eher Unterschiede in der Denkweise als konkrete Zahlen behandeln

  • Wenn man über die „Geschwindigkeit“ einer Sprache spricht, sollte man zwei Dinge betrachten

    1. Welche Kosten die Sprache einem Programm aufprägt
    2. Welche Optimierungen die Sprache ermöglicht
      Rust und C sind schneller als Python oder JS, weil es fast keine Laufzeitprüfungen gibt
      Rust kann allerdings Aliasing-Informationen besser weitergeben und bietet dadurch mehr Optimierungsspielraum
      Im Debug-Modus ist es so langsam wie Ruby, im Release-Modus erreicht es jedoch Geschwindigkeiten auf C-Niveau
    • Diese Sichtweise gefällt mir. Sie hängt auch mit dem C++-Konzept der Zero-Cost Abstraction zusammen
    • Auch JS ist stark optimiert, aber immer noch etwas langsamer als Rust/C
    • Eine weitere Frage ist: „Wie schnell ist es, wenn gewöhnliche Entwickler es benutzen?“ Wichtig ist, ob die Sprache standardmäßig zu schnellem Code hinführt

  • Gegenüber C haben C++ oder Rust mehr Compile-Time-Features, sodass sich schneller Code leichter schreiben lässt
    Zum Beispiel ist dieser Code in C fast unmöglich

    • Andere Beispiele sind CTRE oder fmts compile API.
      In C braucht man dafür externe Werkzeuge wie re2c

  • Assembler ist kein Teil des C-Standards, deshalb lässt es sich schwer direkt mit Rust vergleichen; Rust hat eher einen Charakter, der dem GCC-Projekt nähersteht

  • Ob eine Sprache „schnell“ ist, hängt letztlich von Implementierung und Kontext ab
    Mehr als die Geschwindigkeit der Sprache selbst zählt die Kombination aus Compiler und Hardware
 
aer0700 2026-01-16

Im Durchschnitt weiß ich nicht, welche Sprache am schnellsten ist, aber die Streuung dürfte bei C++ am größten sein.