C und C sind wirklich so schnell?

Während ich mich mit dem Programmieren beschäftige, höre ich, dass C und C die Geschwindigkeitsstandards sind. Das Schnellste vom Schnellsten, direkt in Assembler-Code kompiliert, in der Geschwindigkeit kann nichts mit C oder C mithalten. Und niemand scheint diesen allgemeinen Glauben in Frage zu stellen.

Rechenleistung

Arithmetische Operationen mit Zahlen müssen in C natürlich deutlich schneller funktionieren als in jeder anderen Sprache. Aber tun sie das?
Vor einiger Zeit habe ich beschlossen, eine Reihe einfacher Benchmarks für viele verschiedene Sprachen zu schreiben, um zu sehen, wie groß der Geschwindigkeitsunterschied wirklich ist.
Die Idee war einfach: die Summe einer Milliarde ganzer Zahlen ausgehend von Null mithilfe einfacher Berechnungen zu ermitteln. Einige Compiler (z. B. rustc) ersetzen solche einfachen Zyklen durch Formelausdrücke, die natürlich in konstanter Zeit ausgewertet werden. Um das mit solchen Compilern zu vermeiden. Ähnliches habe ich bei Kostenoperationen mit Zahlen verwendet, wie zum Beispiel bitweise oder.
Nachdem ich Ergebnisse erhalten hatte, war ich sehr überrascht. Meine Weltanschauung stellte sich auf den Kopf und ich musste alles, was ich über die Geschwindigkeit von Programmiersprachen wusste, noch einmal überdenken.
Sie können meine Ergebnisse in der folgenden Tabelle sehen:

Linux 64bit, 1,1 GHz ​​CPU, 4GBRAM

Sprache compiler/version/args Zeit Rost (

Language	compiler/version/args	time
Rust (bitwise or instead of )	rustc 1.75.0 with -O3	167 ms
C	gcc 11.4.0 with -O3	335 ms
NASM	2.15.05	339 ms
Go	1.18.1	340 ms
Java	17.0.13	345 ms
Common Lisp	SBCL 2.1.11	1 sec
Python 3	pypy 3.8.13	1.6 sec
Clojure	1.10.2	9 sec
Python 3	cpython 3.10.12	26 sec
Ruby	3.0.2p107	38 sec

bitweise oder statt ) rustc 1.75.0 mit -O3 167 ms C gcc 11.4.0 mit -O3 335 ms NASM 2.15.05 339 ms Los 1.18.1 340 ms Java 17.0.13 345 ms Gemeinsames Lisp SBCL 2.1.11 1 Sek. Python 3 pypy 3.8.13 1,6 Sek. Clojure 1.10.2 9 Sek. Python 3 cpython 3.10.12 26 Sek. Ruby 3.0.2p107 38 Sek.

Alle Testquellen finden Sie hier:
https://github.com/Taqmuraz/speed-table

Wie wir also sehen können, ist C nicht sehr viel schneller als Java, der Unterschied beträgt etwa 3 %. Außerdem sehen wir, dass andere kompilierte Sprachen in der Leistung arithmetischer Operationen C sehr nahe kommen (Rust ist sogar noch schneller). Dynamische Sprachen, die mit dem JIT-Compiler kompiliert wurden, zeigen schlechtere Ergebnisse – vor allem, weil dort arithmetische Operationen in dynamisch verteilte Funktionen verpackt sind.
Interpretierte dynamische Sprachen ohne JIT-Compiler zeigen die schlechteste Leistung, keine Überraschung.

Leistung der Speicherzuordnung

Nach dieser vernichtenden Niederlage würden C-Fans sagen, dass die Speicherzuweisung in C sehr viel schneller ist, weil Sie sie direkt vom System zuweisen und nicht nach GC fragen.
Ab und zu werde ich den Begriff GC je nach Kontext sowohl als Garbage Collector als auch als verwalteter Heap verwenden.
Warum denken die Leute also, dass GC so langsam ist? Tatsächlich verfügt GC über vorab zugewiesenen Speicher, und bei der Zuweisung wird einfach der Zeiger nach rechts verschoben. Meistens füllt GC den zugewiesenen Speicher mithilfe eines Systemaufrufs mit Nullen, ähnlich wie memset aus C, sodass eine konstante Zeit benötigt wird. Während die Speicherzuweisung in C undefinierte Zeit in Anspruch nimmt, da sie vom System und dem bereits zugewiesenen Speicher abhängt.
Aber selbst unter Berücksichtigung dieses Wissens konnte ich von Java keine so guten Ergebnisse erwarten, wie Sie in den folgenden Tabellen sehen können:

1.1 GHz 2 cores, 4 GB RAM

Running tests on single thread.

Result format : "Xms-Yms ~Z ms" means tests took from X to Y milliseconds, and Z milliseconds in average

1,1 GHz ​​2 Kerne, 4 GBRAM Tests für einzelnen Thread ausführen. Ergebnisformat: „Xms-Yms ~Z ms“ bedeutet, dass Tests zwischen X und Y Millisekunden und im Durchschnitt Z Millisekunden gedauert haben.

Zuweisen von Integer-Arrays

integers array size	times	Java 17.0.13 new[]	C gcc 11.4.0 malloc	Common Lisp SBCL 2.1.11 make-array
16	10000	0-1ms, ~0.9ms	1-2ms, ~1.2ms	0-4ms, ~0.73ms
32	10000	1-3ms, ~1.7ms	1-3ms, ~1.7ms	0-8ms, ~2.ms
1024	10000	6-26ms, ~12ms	21-46ms, ~26ms	12-40ms, ~7ms
2048	10000	9-53ms, ~22ms	24-52ms, ~28ms	12-40ms, ~19ms
16	100000	0-9ms, ~2ms	6-23ms, ~9ms	4-24ms, ~7ms
32	100000	0-14ms, ~3ms	10-15ms, ~11ms	3-8ms, ~7ms
1024	100000	0-113ms, ~16ms	234-1156ms, ~654ms	147-183ms, ~155ms
2048	100000	0-223ms, ~26ms	216-1376ms, ~568ms	299-339ms, ~307ms

Zuweisen einer Instanz der Klasse Person mit einem ganzzahligen Feld.

how many instances	Java 17.0.3 new Person(n)	C g 11.4.0 new Person(n)
100000	0-6ms, ~1.3ms	4-8ms, ~5ms
1 million	0-11ms, ~2ms	43-69ms, ~47ms
1 billion	22-50ms, ~28ms	process terminated

Alle Testquellen finden Sie hier:
https://github.com/Taqmuraz/alloc-table

Dort habe ich insgesamt vier Sprachen getestet: C, C, Java und Lisp. Und Sprachen mit GC zeigen immer bessere Ergebnisse, obwohl ich sie viel strenger getestet habe als C und C . In Java ordne ich beispielsweise Speicher über den virtuellen Funktionsaufruf zu, sodass er möglicherweise nicht statisch optimiert ist, und in Lisp überprüfe ich das erste Element des zugewiesenen Arrays, damit der Compiler den Zuweisungsaufruf nicht überspringt.

Erinnerung freigeben

C-Fans sind immer noch motiviert, ihre Überzeugungen zu schützen, also sagen sie: „Ja, Sie weisen Speicher zwar schneller zu, aber Sie müssen ihn danach freigeben!“.
WAHR. Und plötzlich gibt GC Speicher schneller frei als C. Aber wie? Stellen Sie sich vor, wir haben 1 Million Zuweisungen von GC vorgenommen, aber später haben wir nur noch 1000 Objekte, auf die in unserem Programm verwiesen wird. Und sagen wir mal, diese Objekte sind über die gesamte lange Zeitspanne des Gedächtnisses verteilt. GC führt eine Stapelverfolgung durch, findet diese 1000 „lebenden“ Objekte, verschiebt sie auf den Heap-Peak der vorherigen Generation und setzt den Heap-Peak-Zeiger nach dem letzten von ihnen. Das ist alles.
Also, egal wie viele Objekte Sie zuweisen, GCs Arbeitszeit wird dadurch bestimmt, wie viele davon Sie danach behalten.
Und im Gegensatz dazu müssen Sie in C den gesamten zugewiesenen Speicher manuell freigeben. Wenn Sie also 1 Million Mal Speicher zugewiesen haben, müssen Sie auch 1 Million Freigabeaufrufe durchführen (sonst kommt es zu Speicherlecks). Das heißt, O(1)-O(n) von GC gegen O(n) oder noch schlimmer von C, wobei n ist die Anzahl der zuvor erfolgten Zuweisungen.

Zusammenfassung

Deshalb möchte ich den Sieg der Garbage-Collected-Sprachen über C und C festigen. Hier ist die Übersichtstabelle:

Anforderungen Sprachen mit GC C/C Arithmetik schnell mit

demands	languages with GC	C/C
arithmetic	fast with JIT	fast
allocating memory	fast O(1)	slow
releasing memory	fast O(1) best case, O(n) worst case	O(n) or slower
memory safe	yes	no

JIT schnell Speicher zuweisen schnell O(1) langsam Speicher freigeben schnell O(1) im besten Fall, O(n) im schlechtesten Fall O(n) oder langsamer Speichersicher ja Nein

Jetzt sehen wir vielleicht: Müllabfuhr ist kein notwendiges Übel, sondern das Beste, was wir uns nur wünschen können. Es gibt uns Sicherheit undLeistung beides.

Hommage an C

Obwohl C bei meinen Tests schlechtere Ergebnisse zeigt, ist es immer noch eine wichtige Sprache und hat ein eigenes Anwendungsgebiet. Mein Artikel zielt nicht auf die Ablehnung oder Auslöschung von C ab. C ist nicht schlecht, es ist nur nicht so überlegen, wie die Leute denken. Viele gute Projekte scheiterten nur, weil sich einige Leute für die Verwendung von C anstelle von Java entschieden hatten, weil ihnen beispielsweise gesagt wurde, dass C sehr viel schneller sei und Java aufgrund der Speicherbereinigung unglaublich langsam sei. C ist gut, wenn wir sehr kleine und einfache Programme schreiben. Ich würde jedoch niemals empfehlen, komplexe Programme oder Spiele mit C zu schreiben.

C ist anders

C ist nicht einfach, nicht flexibel, hat eine überladene Syntax und zu viele komplizierte Spezifikationen. Beim Programmieren mit C setzt man keine eigenen Ideen um, kämpft aber in 90 % der Fälle mit Compiler- und Speicherfehlern.
Dieser Artikel zielt auf die Ablehnung von C ab, da Geschwindigkeit und Leistung nur Ausreden sind, die Menschen für die Verwendung dieser Sprache in der Softwareentwicklung anführen. Mit C zahlen Sie mit Ihrer Zeit, Ihrer Programmleistung und Ihrer geistigen Gesundheit. Wenn Sie also die Wahl zwischen C und einer anderen Sprache haben, hoffe ich, dass Sie sich für die letzte entscheiden.

Das obige ist der detaillierte Inhalt vonC und C sind wirklich so schnell?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!