- 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
Noch keine Kommentare.