Sepanjang masa saya terlibat dengan pengaturcaraan, saya mendengar bahawa C dan C ialah standard kelajuan. Terpantas daripada yang terpantas, disusun terus ke kod pemasangan, tiada apa yang boleh bersaing dalam kelajuan dengan C atau C . Dan, nampaknya tiada siapa yang mencabar kepercayaan biasa itu.
Operasi aritmetik dengan nombor, jelas sekali, mesti berfungsi dengan ketara lebih pantas dalam C berbanding dalam mana-mana bahasa lain. Tetapi adakah mereka?
Beberapa waktu lalu saya memutuskan untuk menulis satu set penanda aras mudah untuk dilihat oleh pelbagai bahasa, betapa besarnya perbezaan kelajuan sebenarnya.
Idea adalah mudah: untuk mencari jumlah satu bilion nombor integer, bermula dari sifar, menggunakan pengkomputeran lurus ke hadapan. Sesetengah penyusun (rustc, sebagai contoh) menggantikan kitaran mudah sedemikian dengan ungkapan formula, yang, sudah tentu, akan dinilai dalam masa yang tetap. Untuk mengelakkannya dengan penyusun sedemikian. Saya menggunakan yang serupa dalam operasi kos dengan nombor, seperti bitwise atau.
Selepas saya mendapat keputusan, saya sangat terkejut. Pandangan dunia saya terbalik, dan saya terpaksa mempertimbangkan semula semua yang saya tahu tentang kelajuan bahasa pengaturcaraan.
Anda boleh melihat keputusan saya dalam jadual di bawah :
Linux 64bit, 1.1 GHz CPU, 4GB RAM
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 |
Semua sumber ujian yang mungkin anda temui di sini :
https://github.com/Taqmuraz/speed-table
Jadi, seperti yang mungkin kita lihat, C tidak jauh lebih pantas daripada Java, perbezaannya adalah kira-kira 3%. Selain itu, kami melihat bahawa bahasa terkumpul lain sangat hampir dalam prestasi operasi aritmetik dengan C (Karat lebih cepat). Bahasa dinamik, yang disusun dengan Pengkompil JIT, menunjukkan hasil yang lebih teruk -- kebanyakannya kerana operasi aritmetik dibalut ke dalam fungsi yang dihantar secara dinamik di sana.
Bahasa dinamik yang ditafsirkan tanpa pengkompil JIT menunjukkan prestasi paling teruk, bukan kejutan.
Selepas kekalahan teruk itu, peminat C akan mengatakan bahawa peruntukan memori dalam C adalah lebih cepat, kerana anda memperuntukkannya terus daripada sistem, bukan meminta GC.
Sekarang dan selepas ini saya akan menggunakan istilah GC sebagai pengumpul sampah dan sebagai timbunan terurus, bergantung pada konteks.
Jadi, mengapa orang berfikir, bahawa GC sangat lambat? Malah, GC mempunyai memori yang telah diperuntukkan terlebih dahulu dan peruntukan adalah hanya mengalihkan penunjuk ke kanan. Kebanyakannya GC mengisi memori yang diperuntukkan dengan sifar menggunakan panggilan sistem, serupa dengan memset daripada C, jadi ia mengambil masa malar. Walaupun peruntukan memori dalam C mengambil masa yang tidak ditentukan, kerana ia bergantung pada sistem dan memori yang telah diperuntukkan.
Tetapi, walaupun mempertimbangkan pengetahuan ini, saya tidak dapat mengharapkan hasil yang begitu baik dari Java, yang mungkin anda lihat dalam jadual berikut :
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 |
Semua sumber ujian yang mungkin anda temui di sini :
https://github.com/Taqmuraz/alloc-table
Di sana saya menguji empat bahasa secara keseluruhan: C, C , Java dan Lisp. Dan, bahasa dengan GC sentiasa menunjukkan hasil yang lebih baik, walaupun saya mengujinya dengan lebih ketat, berbanding C dan C . Sebagai contoh, di Java saya memperuntukkan memori melalui panggilan fungsi maya, jadi ia mungkin tidak dioptimumkan secara statik, dan dalam Lisp saya menyemak elemen pertama tatasusunan yang diperuntukkan, jadi pengkompil tidak akan melangkau panggilan peruntukan.
Peminat C masih bermotivasi untuk melindungi kepercayaan mereka, jadi, mereka berkata "Ya, anda memperuntukkan memori lebih cepat, tetapi anda perlu melepaskannya selepas itu!".
betul. Dan, tiba-tiba, GC mengeluarkan memori lebih cepat, daripada C. Tetapi bagaimana? Bayangkan, kami membuat 1 juta peruntukan daripada GC, tetapi kemudian kami hanya mempunyai 1000 objek yang dirujuk dalam program kami. Dan, katakan, objek tersebut diedarkan melalui semua rentang memori yang panjang itu. GC melakukan pengesanan tindanan, mencari 1000 objek "hidup" itu, mengalihkannya ke puncak timbunan generasi sebelumnya dan meletakkan penuding puncak timbunan selepas yang terakhir daripadanya. Itu sahaja.
Jadi, tidak kira, berapa banyak objek yang anda peruntukkan, masa kerja GC ditentukan oleh berapa banyak objek yang anda simpan selepas.
Dan, bertentangan dengan itu, dalam C anda perlu melepaskan semua memori yang diperuntukkan secara manual, jadi, jika anda memperuntukkan memori 1 juta kali, anda perlu membuat 1 juta panggilan keluaran juga (atau anda akan mengalami kebocoran memori). Ini bermakna, O(1)-O(n) daripada GC menentang O(n) atau lebih teruk daripada C, di mana n ialah bilangan peruntukan yang berlaku sebelum ini.
Jadi, saya ingin menyatukan kemenangan bahasa kutipan sampah ke atas C dan C . Berikut ialah jadual ringkasan :
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 |
Sekarang kita boleh lihat -- kutipan sampah bukanlah kejahatan yang perlu, tetapi perkara terbaik yang kita hanya ingin miliki. Ia memberi kita keselamatan dan prestasi kedua-duanya.
Walaupun C menunjukkan keputusan yang lebih teruk pada ujian saya, ia masih merupakan bahasa yang penting dan ia mempunyai medan aplikasi sendiri. Artikel saya tidak bertujuan untuk penolakan atau pemansuhan C. C tidaklah teruk, cuma ia tidaklah sehebat yang difikirkan orang. Banyak projek yang baik runtuh hanya kerana sesetengah orang memutuskan untuk menggunakan C dan bukannya Java, sebagai contoh, kerana mereka telah diberitahu bahawa C adalah lebih pantas, dan Java adalah sangat perlahan kerana pengumpulan sampah. C adalah baik, apabila kita menulis program yang sangat kecil dan mudah. Tetapi, saya tidak akan mengesyorkan menulis program atau permainan yang kompleks dengan C.
C tidak mudah, tidak fleksibel, mempunyai sintaks yang berlebihan dan spesifikasi yang terlalu rumit. Pengaturcaraan dengan C anda tidak akan melaksanakan idea sendiri tetapi melawan dengan ralat pengkompil dan ingatan 90% pada setiap masa.
Artikel ini menyasarkan penolakan C , kerana kelajuan dan prestasi hanyalah alasan orang ramai menggunakan bahasa ini dalam pembangunan perisian. Menggunakan C , anda membayar dengan masa anda, prestasi program anda dan kesihatan mental anda. Jadi, apabila anda mempunyai pilihan antara C dan sebarang bahasa lain, saya harap anda memilih yang terakhir.
Atas ialah kandungan terperinci C dan C sangat pantas?. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!