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.
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
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 |
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.
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 |
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 |
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.
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.
Deshalb möchte ich den Sieg der Garbage-Collected-Sprachen über C und C festigen. Hier ist die Übersichtstabelle:
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 |
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.
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 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!