Seberapa cepatkah C ++ daripada C #?

Atau sekarang sebaliknya?

Dari apa yang saya dengar ada beberapa area di mana C # terbukti lebih cepat daripada C ++, tapi saya tidak pernah punya nyali untuk mengujinya sendiri.

Saya kira ada di antara Anda yang bisa menjelaskan perbedaan ini secara terperinci atau mengarahkan saya ke tempat yang tepat untuk mendapatkan informasi mengenai hal ini.

Tidak ada alasan ketat mengapa bahasa berbasis bytecode seperti C # atau Java yang memiliki JIT tidak bisa secepat kode C ++. Namun kode C ++ dulu secara signifikan lebih cepat untuk waktu yang lama, dan juga saat ini masih dalam banyak kasus. Ini terutama disebabkan oleh optimisasi JIT yang lebih maju yang rumit untuk diimplementasikan, dan yang sangat keren baru saja tiba.

Jadi C ++ lebih cepat, dalam banyak kasus. Tetapi ini hanya sebagian dari jawabannya. Kasus-kasus di mana C ++ sebenarnya lebih cepat, adalah program yang sangat dioptimalkan, di mana programmer ahli secara menyeluruh dioptimalkan keluar dari kode. Ini tidak hanya sangat memakan waktu (dan karenanya mahal), tetapi juga umumnya menyebabkan kesalahan karena optimasi yang berlebihan.

Di sisi lain, kode dalam bahasa yang ditafsirkan menjadi lebih cepat di versi runtime yang lebih baru (.NET CLR atau Java VM), tanpa Anda melakukan apa pun. Dan ada banyak optimisasi bermanfaat yang dapat dilakukan oleh kompiler JIT yang tidak mungkin dilakukan dalam bahasa dengan pointer. Juga, beberapa orang berpendapat bahwa pengumpulan sampah umumnya harus secepat atau lebih cepat daripada manajemen memori manual, dan dalam banyak kasus memang demikian. Anda umumnya dapat mengimplementasikan dan mencapai semua ini dalam C ++ atau C, tetapi itu akan menjadi jauh lebih rumit dan rawan kesalahan.

Seperti yang dikatakan Donald Knuth, "optimasi prematur adalah akar dari semua kejahatan". Jika Anda benar-benar tahu pasti bahwa aplikasi Anda sebagian besar akan terdiri dari aritmatika sangat kritis, dan itu akan menjadi hambatan, dan itu pasti akan lebih cepat di C ++, dan Anda yakin bahwa C ++ tidak akan bertentangan dengan yang lain persyaratan, pilih C ++. Dalam kasus lain, berkonsentrasilah pada penerapan pertama aplikasi Anda dengan benar dalam bahasa apa pun yang paling sesuai untuk Anda, kemudian temukan kemacetan kinerja jika berjalan terlalu lambat, dan kemudian pikirkan tentang bagaimana mengoptimalkan kode. Dalam kasus terburuk, Anda mungkin perlu memanggil kode C melalui antarmuka fungsi asing, sehingga Anda masih memiliki kemampuan untuk menulis bagian-bagian penting dalam bahasa tingkat yang lebih rendah.

Ingatlah bahwa relatif mudah untuk mengoptimalkan program yang benar, tetapi jauh lebih sulit untuk memperbaiki program yang dioptimalkan.

Memberikan persentase keuntungan kecepatan yang sebenarnya adalah tidak mungkin, itu sangat tergantung pada kode Anda. Dalam banyak kasus, implementasi bahasa pemrograman bahkan tidak menjadi hambatan. Ambil patokan di http://benchmarksgame.alioth.debian.org/ dengan banyak keraguan, karena ini sebagian besar menguji kode aritmatika, yang kemungkinan besar tidak mirip dengan kode Anda sama sekali.

C # mungkin tidak lebih cepat, tetapi itu membuat ANDA / ME lebih cepat. Itu ukuran paling penting untuk apa yang saya lakukan. :)

Lima jeruk lebih cepat. Atau lebih tepatnya: tidak ada jawaban selimut (benar). C ++ adalah bahasa yang dikompilasi secara statis (tapi kemudian, ada optimasi dipandu profil juga), C # berjalan dibantu oleh kompiler JIT. Ada begitu banyak perbedaan sehingga pertanyaan-pertanyaan seperti "seberapa cepat" tidak dapat dijawab, bahkan dengan memberi perintah besar.

Saya akan mulai dengan tidak setuju dengan bagian dari jawaban yang diterima (dan diputuskan dengan baik) untuk pertanyaan ini dengan menyatakan:

Sebenarnya ada banyak alasan mengapa kode JITted akan berjalan lebih lambat daripada program C ++ yang dioptimalkan dengan benar (atau bahasa lain tanpa overhead runtime) termasuk:

• menghitung siklus yang dihabiskan pada kode JITting pada saat runtime menurut definisi tidak tersedia untuk digunakan dalam eksekusi program.

• setiap jalur panas di JITter akan bersaing dengan kode Anda untuk instruksi dan cache data di CPU. Kita tahu bahwa cache mendominasi dalam hal kinerja dan bahasa asli seperti C ++ tidak memiliki jenis pertikaian ini, menurut definisi.

• anggaran waktu pengoptimal waktu berjalan tentu jauh lebih terbatas daripada pengoptimal waktu kompilasi (seperti yang ditunjukkan komentator lain)

Intinya: Pada akhirnya, Anda akan hampir pasti dapat membuat implementasi lebih cepat di C ++ dari yang Anda bisa dalam C # .

Sekarang, dengan mengatakan, seberapa cepat sebenarnya tidak dapat diukur, karena ada terlalu banyak variabel: tugas, domain masalah, perangkat keras, kualitas implementasi, dan banyak faktor lainnya. Anda akan menjalankan tes pada skenario Anda untuk menentukan perbedaan dalam kinerja, dan kemudian memutuskan apakah itu sepadan dengan upaya tambahan dan kompleksitas.

Ini adalah topik yang sangat panjang dan kompleks, tetapi saya merasa perlu menyebutkan demi kelengkapan bahwa optimizer runtime C # sangat baik, dan mampu melakukan optimasi dinamis tertentu pada saat runtime yang tidak tersedia untuk C ++ dengan waktu kompilasi ( statis) pengoptimal. Bahkan dengan ini, keuntungannya masih sangat dalam di pengadilan aplikasi asli, tetapi pengoptimal dinamis adalah alasan untuk "kualifikasi hampir pasti" yang diberikan di atas.

-

Dalam hal kinerja relatif, saya juga terganggu oleh angka-angka dan diskusi yang saya lihat di beberapa jawaban lain, jadi saya pikir saya akan berpadu dan pada saat yang sama, memberikan beberapa dukungan untuk pernyataan yang saya buat di atas.

Sebagian besar masalah dengan tolok ukur tersebut adalah Anda tidak dapat menulis kode C ++ seolah-olah Anda sedang menulis C # dan berharap mendapatkan hasil yang representatif (mis. Melakukan ribuan alokasi memori di C ++ akan memberi Anda angka yang mengerikan.)

Alih-alih, saya menulis kode C ++ yang idiomatis dan membandingkannya dengan kode C # @Wiory yang disediakan. Dua perubahan besar yang saya buat pada kode C ++ adalah:

1) menggunakan vektor :: cadangan ()

2) meratakan array 2d menjadi 1d untuk mencapai lokalitas cache yang lebih baik (blok yang berdekatan)

C # (.NET 4.6.1)

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);
}

Run time (Release): Init: 124ms, Isi: 165ms

C ++ 14 (Dentang v3.8 / C2)

#include <iostream>
#include <vector>

auto TestSuite::ColMajorArray()
{
    constexpr size_t ROWS = 5000;
    constexpr size_t COLS = 9000;

    auto initStart = std::chrono::steady_clock::now();

    auto arr = std::vector<double>();
    arr.reserve(ROWS * COLS);

    auto initFinish = std::chrono::steady_clock::now();
    auto initTime = std::chrono::duration_cast<std::chrono::microseconds>(initFinish - initStart);

    auto fillStart = std::chrono::steady_clock::now();

    for(auto i = 0, r = 0; r < ROWS; ++r)
    {
        for (auto c = 0; c < COLS; ++c)
        {
            arr[i++] = static_cast<double>(r * c);
        }
    }

    auto fillFinish = std::chrono::steady_clock::now();
    auto fillTime = std::chrono::duration_cast<std::chrono::milliseconds>(fillFinish - fillStart);

    return std::make_pair(initTime, fillTime);
}

Jalankan waktu (Rilis): Init: 398µs (ya, itu mikrodetik), Isi: 152ms

Total waktu Jalankan: C #: 289ms, C ++ 152ms (kira-kira 90% lebih cepat)

Pengamatan

• Mengubah implementasi C # ke implementasi array 1d yang sama menghasilkan Init: 40ms, Isi: 171ms, Total: 211ms ( C ++ masih hampir 40% lebih cepat ).

• Jauh lebih sulit untuk mendesain dan menulis kode "cepat" dalam C ++ daripada menulis kode "biasa" dalam kedua bahasa.

• Sangat mudah untuk mendapatkan kinerja yang buruk di C ++; kami melihat bahwa dengan kinerja vektor tanpa pagu harga. Dan ada banyak jebakan seperti ini.

• Kinerja C # agak luar biasa ketika Anda mempertimbangkan semua yang terjadi saat runtime. Dan kinerja itu relatif mudah diakses.

• Lebih banyak data anekdotal yang membandingkan kinerja C ++ dan C #: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore

Intinya adalah bahwa C ++ memberi Anda lebih banyak kontrol atas kinerja. Apakah Anda ingin menggunakan pointer? Referensi? Stack memory? Tumpukan? Polimorfisme dinamis atau menghilangkan overhead runtime dari suatu vtable dengan polimorfisme statis (via templat / CRTP)? Dalam C ++ Anda harus ... er, bisa membuat semua pilihan ini (dan lebih) sendiri, idealnya sehingga solusi terbaik alamat masalah Anda penanggulangan sedang.

Tanyakan pada diri Anda apakah Anda benar-benar ingin atau memerlukan kontrol itu, karena bahkan untuk contoh sepele di atas, Anda dapat melihat bahwa meskipun ada peningkatan kinerja yang signifikan, itu memerlukan investasi yang lebih dalam untuk mengakses.

Dalam pengalaman saya (dan saya telah banyak bekerja dengan kedua bahasa), masalah utama dengan C # dibandingkan dengan C ++ adalah konsumsi memori yang tinggi, dan saya belum menemukan cara yang baik untuk mengendalikannya. Itu adalah konsumsi memori yang akhirnya akan memperlambat perangkat lunak .NET.

Faktor lain adalah bahwa kompiler JIT tidak dapat menyediakan terlalu banyak waktu untuk melakukan optimasi tingkat lanjut, karena ia berjalan pada saat runtime, dan pengguna akhir akan melihatnya jika membutuhkan terlalu banyak waktu. Di sisi lain, kompiler C ++ memiliki semua waktu yang diperlukan untuk melakukan optimasi pada waktu kompilasi. Faktor ini jauh lebih kecil daripada konsumsi memori, IMHO.

Satu skenario khusus di mana C ++ masih berada di atas angin (dan akan, untuk tahun-tahun mendatang) terjadi ketika keputusan polimorfik dapat ditentukan sebelumnya pada waktu kompilasi.

Secara umum, enkapsulasi dan pengambilan keputusan yang ditangguhkan adalah hal yang baik karena membuat kode lebih dinamis, lebih mudah untuk beradaptasi dengan perubahan persyaratan dan lebih mudah digunakan sebagai kerangka kerja. Inilah sebabnya mengapa pemrograman berorientasi objek dalam C # sangat produktif dan dapat digeneralisasi dengan istilah “generalisasi”. Sayangnya, generalisasi jenis ini dikenakan biaya saat run-time.

Biasanya, biaya ini tidak substansial tetapi ada aplikasi di mana overhead panggilan metode virtual dan pembuatan objek dapat membuat perbedaan (terutama karena metode virtual mencegah optimasi lainnya seperti inlining panggilan metode). Di sinilah C ++ memiliki keuntungan besar karena Anda dapat menggunakan templat untuk mencapai jenis generalisasi yang berbeda yang tidak memiliki berdampak pada runtime tetapi belum tentu kurang polimorfik daripada OOP. Bahkan, semua mekanisme yang merupakan OOP dapat dimodelkan hanya menggunakan teknik templat dan resolusi waktu kompilasi.

Dalam kasus seperti itu (dan memang, mereka sering terbatas pada domain masalah khusus), C ++ menang melawan C # dan bahasa yang sebanding.

C ++ (atau C dalam hal ini) memberi Anda kendali atas struktur data Anda. Jika Anda ingin bermain-main, Anda memiliki opsi itu. Aplikasi Java atau .NET yang dikelola besar (OWB, Visual Studio 2005 ) yang menggunakan struktur data internal perpustakaan Java / .NET membawa bagasi. Saya telah melihat sesi desainer OWB menggunakan lebih dari 400 MB RAM dan BIDS untuk desain kubus atau ETL masuk ke 100-an MB juga.

Pada beban kerja yang dapat diprediksi (seperti kebanyakan tolok ukur yang mengulangi proses berkali-kali) JIT dapat memberi Anda kode yang dioptimalkan dengan cukup baik sehingga tidak ada perbedaan praktis.

IMO pada aplikasi besar perbedaannya tidak begitu banyak JIT seperti struktur data yang menggunakan kode itu sendiri. Di mana suatu aplikasi adalah memori-berat Anda akan mendapatkan penggunaan cache yang kurang efisien. Kehilangan cache pada CPU modern cukup mahal. Di mana C atau C ++ benar-benar menang adalah di mana Anda dapat mengoptimalkan penggunaan struktur data untuk bermain dengan baik dengan cache CPU.

Untuk grafik, kelas C # Graphics standar jauh lebih lambat daripada GDI yang diakses melalui C / C ++. Saya tahu ini tidak ada hubungannya dengan bahasa per se, lebih dengan total. NET platform, tetapi Grafik adalah apa yang ditawarkan kepada pengembang sebagai pengganti GDI, dan kinerjanya sangat buruk saya bahkan tidak berani melakukan grafik dengan itu.

Kami memiliki tolok ukur sederhana yang kami gunakan untuk melihat seberapa cepat perpustakaan grafis, dan itu hanya menggambar garis acak di jendela. C ++ / GDI masih tajam dengan 10.000 baris sementara C # / Grafik mengalami kesulitan melakukan 1000 secara real-time.

Pengumpulan sampah adalah alasan utama Java # CANNOT digunakan untuk sistem waktu-nyata.

1. Kapan GC akan terjadi?

2. Itu akan makan waktu berapa lama?

Ini tidak menentukan.

Kami harus menentukan apakah C # sebanding dengan C ++ dalam kinerja dan saya menulis beberapa program pengujian untuk itu (menggunakan Visual Studio 2005 untuk kedua bahasa). Ternyata tanpa pengumpulan sampah dan hanya mempertimbangkan bahasa (bukan kerangka kerja) C # pada dasarnya memiliki kinerja yang sama dengan C ++. Alokasi memori jauh lebih cepat di C # daripada di C ++ dan C # memiliki sedikit keunggulan dalam determinisme ketika ukuran data meningkat di luar batas garis cache. Namun, semua ini akhirnya harus dibayar dan ada biaya besar dalam bentuk hit kinerja non-deterministik untuk C # karena pengumpulan sampah.

Seperti biasa, itu tergantung aplikasi. Ada kasus di mana C # mungkin diabaikan lebih lambat, dan kasus lain di mana C ++ adalah 5 atau 10 kali lebih cepat, terutama dalam kasus di mana operasi dapat dengan mudah dilakukan dengan SIMD.

Saya tahu itu bukan apa yang Anda minta, tetapi C # seringkali lebih cepat untuk ditulis daripada C ++, yang merupakan bonus besar dalam pengaturan komersial.

C / C ++ dapat melakukan jauh lebih baik dalam program-program di mana ada array besar atau perulangan berat / iterasi atas array (ukuran apa pun). Ini adalah alasan bahwa grafik umumnya jauh lebih cepat di C / C ++, karena operasi array yang berat mendasari hampir semua operasi grafis. NET dikenal sangat lambat dalam operasi pengindeksan array karena semua pemeriksaan keamanan, dan ini terutama berlaku untuk array multi-dimensi (dan, ya, array C # persegi panjang bahkan lebih lambat daripada array C # bergerigi).

Bonus C / C ++ paling jelas jika Anda tetap menggunakan pointer dan menghindari Boost, std::vectordan wadah tingkat tinggi lainnya, serta inlinesetiap fungsi kecil yang mungkin. Gunakan array old-school jika memungkinkan. Ya, Anda akan membutuhkan lebih banyak baris kode untuk mencapai hal yang sama dengan yang Anda lakukan di Java atau C # saat Anda menghindari kontainer tingkat tinggi. Jika Anda membutuhkan array berukuran dinamis, Anda hanya perlu ingat untuk memasangkan Anda new T[]dengan yang sesuaidelete[] pernyataan (atau gunakanstd::unique_ptr) - harga untuk kecepatan ekstra adalah Anda harus kode lebih hati-hati. Tetapi sebagai gantinya, Anda bisa membebaskan diri Anda sendiri dari overhead memori yang dikelola / pengumpul sampah, yang dapat dengan mudah 20% atau lebih dari waktu pelaksanaan program berorientasi objek baik di Jawa dan .NET, serta yang dikelola secara besar-besaran biaya pengindeksan array memori. Aplikasi C ++ juga dapat mengambil manfaat dari beberapa sakelar kompiler yang bagus dalam kasus tertentu tertentu.

Saya seorang programmer ahli dalam C, C ++, Java, dan C #. Baru-baru ini saya memiliki kesempatan langka untuk mengimplementasikan program algoritmik yang sama persis dalam 3 bahasa terakhir. Program ini memiliki banyak operasi array matematika dan multi-dimensi. Saya sangat mengoptimalkan ini dalam semua 3 bahasa. Hasilnya khas dari apa yang biasanya saya lihat dalam perbandingan yang kurang ketat: Java sekitar 1.3x lebih cepat dari C # (sebagian besar JVM lebih dioptimalkan daripada CLR), dan versi raw pointer C ++ datang sekitar 2.1x lebih cepat daripada C #. Perhatikan bahwa program C # hanya menggunakan kode aman — menurut pendapat saya Anda sebaiknya menuliskannya dalam C ++ sebelum menggunakan unsafekata kunci.

Supaya tidak ada yang berpikir saya memiliki sesuatu terhadap C #, saya akan menutup dengan mengatakan bahwa C # mungkin adalah bahasa favorit saya. Ini adalah bahasa pengembangan yang paling logis, intuitif dan cepat yang saya temui sejauh ini. Saya melakukan semua prototipe saya di C #. Bahasa C # memiliki banyak keunggulan kecil dan halus di atas Java (ya, saya tahu Microsoft memiliki kesempatan untuk memperbaiki banyak kekurangan Java dengan memasukkan game terlambat dan bisa juga menyalin Java). Bersulang untuk Calendarkelas Java siapa pun? Jika Microsoft pernah mengeluarkan upaya nyata untuk mengoptimalkan CLR dan .NET JITter, C # dapat dengan serius mengambil alih. Saya benar-benar terkejut mereka belum melakukannya — mereka melakukan banyak hal dengan benar dalam bahasa C #, mengapa tidak menindaklanjutinya dengan optimisasi kompiler yang sangat memukul? Mungkin jika kita semua memohon.

> Dari apa yang saya dengar ...

Kesulitan Anda tampaknya dalam memutuskan apakah apa yang Anda dengar kredibel, dan kesulitan itu hanya akan terulang ketika Anda mencoba menilai balasan di situs ini.

Bagaimana Anda akan memutuskan apakah hal-hal yang orang katakan di sini lebih atau kurang kredibel daripada apa yang Anda dengar sebelumnya?

Salah satu caranya adalah dengan meminta bukti .

Ketika seseorang mengklaim "ada beberapa area di mana C # terbukti lebih cepat daripada C ++" tanyakan kepada mereka mengapa mereka mengatakan itu , minta mereka menunjukkan pengukuran kepada Anda, minta mereka untuk menunjukkan kepada Anda program. Terkadang mereka hanya melakukan kesalahan. Kadang-kadang Anda akan menemukan bahwa mereka hanya mengekspresikan pendapat daripada membagikan sesuatu yang mereka anggap benar.

Seringkali informasi dan pendapat akan campur aduk dalam apa yang diklaim orang, dan Anda harus mencoba dan memilah mana. Misalnya, dari balasan di forum ini:

• "Ambil patokan di http://shootout.alioth.debian.org/ dengan banyak skeptis, karena ini sebagian besar menguji kode aritmatika, yang kemungkinan besar tidak mirip dengan kode Anda sama sekali."

  Tanyakan pada diri Anda apakah Anda benar-benar mengerti apa "kode aritmatika yang sebagian besar menguji" ini , dan kemudian tanyakan pada diri Anda apakah penulis telah benar-benar menunjukkan kepada Anda bahwa klaimnya benar.

• "Itu adalah tes yang agak tidak berguna, karena itu benar-benar tergantung pada seberapa baik masing-masing program telah dioptimalkan; Saya telah berhasil mempercepat beberapa dari mereka dengan 4-6 kali atau lebih, menjadikannya jelas bahwa perbandingan antara program yang tidak dioptimalkan agak bodoh."

  Tanyakan pada diri Anda apakah penulis telah benar-benar menunjukkan kepada Anda bahwa ia berhasil "mempercepat beberapa dari mereka dengan 4-6 kali atau lebih" - itu adalah klaim yang mudah dibuat!

Untuk masalah 'paralel memalukan', ketika menggunakan Intel TBB dan OpenMP pada C ++ saya telah mengamati peningkatan kinerja sekitar 10x dibandingkan dengan masalah (matematika murni) serupa yang dilakukan dengan C # dan TPL. SIMD adalah salah satu area di mana C # tidak dapat bersaing, tetapi saya juga mendapat kesan bahwa TPL memiliki overhead yang cukup besar.

Yang mengatakan, saya hanya menggunakan C ++ untuk tugas-tugas penting di mana saya tahu saya akan dapat melakukan multithread dan mendapatkan hasil dengan cepat. Untuk yang lainnya, C # (dan kadang-kadang F #) baik-baik saja.

Ini adalah pertanyaan yang sangat samar tanpa jawaban pasti yang nyata.

Sebagai contoh; Saya lebih suka memainkan game 3D yang dibuat di C ++ daripada di C #, karena kinerjanya tentu jauh lebih baik. (Dan saya tahu XNA, dll., Tetapi tidak mendekati hal yang sebenarnya).

Di sisi lain, seperti yang disebutkan sebelumnya; Anda harus mengembangkan dalam bahasa yang memungkinkan Anda melakukan apa yang Anda inginkan dengan cepat, dan jika perlu optimalkan.

Bahasa .NET dapat secepat kode C ++, atau bahkan lebih cepat, tetapi kode C ++ akan memiliki throughput yang lebih konstan karena .NET runtime harus berhenti sebentar untuk GC , bahkan jika itu sangat pintar tentang jeda-nya.

Jadi, jika Anda memiliki beberapa kode yang harus berjalan cepat secara konsisten tanpa jeda, .NET akan memperkenalkan latensi di beberapa titik , bahkan jika Anda sangat berhati-hati dengan runtime GC.

Secara teori, untuk aplikasi tipe server yang berjalan lama, bahasa yang dikompilasi JIT bisa menjadi banyak lebih cepat daripada rekan yang dikompilasi secara asli. Karena bahasa yang dikompilasi JIT umumnya pertama kali dikompilasi ke bahasa perantara tingkat yang cukup rendah, Anda dapat melakukan banyak optimasi tingkat tinggi tepat pada waktu kompilasi. Keuntungan besar datang bahwa JIT dapat terus mengkompilasi ulang bagian kode dengan cepat karena semakin banyak data tentang bagaimana aplikasi sedang digunakan. Itu dapat mengatur jalur kode yang paling umum untuk memungkinkan prediksi cabang berhasil sesering mungkin. Itu dapat mengatur ulang blok kode terpisah yang sering dipanggil bersama untuk menyimpan keduanya di cache. Ini dapat menghabiskan lebih banyak upaya mengoptimalkan loop batin.

Saya ragu bahwa ini dilakukan oleh .NET atau salah satu JRE, tetapi sedang diteliti kembali ketika saya masih di universitas, jadi itu tidak masuk akal untuk berpikir bahwa hal-hal semacam ini dapat menemukan jalan mereka ke dunia nyata di beberapa titik segera .

Aplikasi yang membutuhkan akses memori intensif misalnya. manipulasi gambar biasanya lebih baik ditulis dalam lingkungan yang tidak dikelola (C ++) daripada yang dikelola (C #). Loop batin yang dioptimalkan dengan pointer arithmetics jauh lebih mudah dikendalikan di C ++. Dalam C # Anda mungkin perlu menggunakan kode yang tidak aman untuk mendekati kinerja yang sama.

Saya telah menguji vectordi C ++ dan C # setara - Listdan array 2d sederhana.

Saya menggunakan edisi Visual C # / C ++ 2010 Express. Kedua proyek tersebut adalah aplikasi konsol sederhana, saya telah mengujinya dalam mode pelepasan dan debug standar (tanpa pengaturan khusus). Daftar C # berjalan lebih cepat di pc saya, inisialisasi array juga lebih cepat di C #, operasi matematika lebih lambat.

Saya menggunakan Intel Core2Duo [email protected], C # - .NET 4.0.

Saya tahu bahwa implementasi vektor berbeda dari daftar C #, tetapi saya hanya ingin menguji koleksi yang akan saya gunakan untuk menyimpan objek saya (dan dapat menggunakan indeks accessor).

Tentu saja Anda perlu mengosongkan memori (katakanlah untuk setiap penggunaan new), tapi saya ingin menjaga kode tetap sederhana.

Tes C ++ vektor :

static void TestVector()
{
    clock_t start,finish;
    start=clock();
    vector<vector<double>> myList=vector<vector<double>>();
    int i=0;
    for( i=0; i<500; i++)
    {
        myList.push_back(vector<double>());
        for(int j=0;j<50000;j++)
            myList[i].push_back(j+i);
    }
    finish=clock();
    cout<<(finish-start)<<endl;
    cout<<(double(finish - start)/CLOCKS_PER_SEC);
}

Tes daftar C #:

private static void TestVector()
{

    DateTime t1 = System.DateTime.Now;
    List<List<double>> myList = new List<List<double>>();
    int i = 0;
    for (i = 0; i < 500; i++)
    {
        myList.Add(new List<double>());
        for (int j = 0; j < 50000; j++)
            myList[i].Add(j *i);
    }
    DateTime t2 = System.DateTime.Now;
    Console.WriteLine(t2 - t1);
}

C ++ - array:

static void TestArray()
{
    cout << "Normal array test:" << endl;
    const int rows = 5000;
    const int columns = 9000;
    clock_t start, finish;

    start = clock();
    double** arr = new double*[rows];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    finish = clock();

    cout << (finish - start) << endl;

    start = clock();
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    finish = clock();

    cout << (finish - start) << endl;
}

C # - array:

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i * j;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

}

Waktu: (Rilis / Debug)

C ++

• 600/606 ms array init,
• Isi array 200/270 ms,
• 1sec / 13sec vektor init & isi.

(Ya, 13 detik, saya selalu memiliki masalah dengan daftar / vektor dalam mode debug.)

C #:

• 20/20 ms array init,
• Isi array 403/440 ms,
• 710/742 ms daftar init & fill.

Yah, itu tergantung. Jika byte-code diterjemahkan ke dalam mesin-code (dan bukan hanya JIT) (maksud saya jika Anda menjalankan program) dan jika program Anda menggunakan banyak alokasi / deallocations itu bisa lebih cepat karena algoritma GC hanya perlu satu pass (secara teoritis) melalui seluruh memori sekali, tetapi panggilan malloc / realloc / free C / C ++ normal menyebabkan overhead pada setiap panggilan (call-overhead, overhead struktur data, cache misses;)).

Jadi secara teori dimungkinkan (juga untuk bahasa GC lainnya).

Saya tidak benar-benar melihat kelemahan ekstrim dari tidak dapat menggunakan metaprogramming dengan C # untuk sebagian besar aplikasi, karena kebanyakan programmer tidak menggunakannya.

Keuntungan besar lainnya adalah bahwa SQL, seperti "ekstensi" LINQ , memberikan peluang bagi kompiler untuk mengoptimalkan panggilan ke basis data (dengan kata lain, kompiler dapat mengkompilasi seluruh LINQ ke satu "gumpalan" biner di mana fungsi yang dipanggil digariskan atau untuk penggunaan Anda dioptimalkan, tapi saya berspekulasi di sini).

Saya kira ada aplikasi yang ditulis dalam C # berjalan cepat, serta ada lebih banyak aplikasi C ++ tertulis berjalan cepat (baik C ++ hanya lebih tua ... dan mengambil UNIX juga ...)
- pertanyaannya adalah - apa itu, pengguna dan pengembang mengeluh tentang ... Untuk menulis kode dalam C # sangat sederhana dan cepat (jangan lupa itu juga meningkatkan kemungkinan kesalahan. Dalam kasus C ++, pengembang mengeluh kebocoran memori, - berarti penghancuran, panggilan antara DLL, serta "DLL hell" - masalah dengan dukungan dan penggantian perpustakaan dengan yang lebih baru ... Saya rasa lebih banyak keterampilan yang Anda miliki dalam bahasa pemrograman, semakin banyak kualitas (dan kecepatan) yang menjadi ciri perangkat lunak Anda.
Nah, IMHO, dalam kasus C # kami memiliki UI yang sangat nyaman, hierarki perpustakaan yang sangat bagus, dan seluruh sistem antarmuka CLI. Dalam kasus C ++ kami memiliki template, ATL, COM, MFC dan seluruh kode yang sudah ditulis dan menjalankan kode seperti OpenGL, DirectX dan sebagainya ... Pengembang mengeluh panggilan GC yang meningkat secara tidak pasti dalam kasus C # (berarti program berjalan cepat, dan dalam satu detik - bang! ini macet).

Saya akan begini: programmer yang menulis kode lebih cepat, adalah orang-orang yang lebih mengetahui apa yang membuat mesin saat ini berjalan cepat, dan kebetulan mereka juga orang-orang yang menggunakan alat yang tepat yang memungkinkan tingkat rendah yang tepat dan deterministik teknik optimasi. Untuk alasan ini, orang-orang ini adalah orang-orang yang menggunakan C / C ++ daripada C #. Saya akan mengatakan hal ini sebagai fakta.

Jika saya tidak salah, template C # ditentukan saat runtime. Ini harus lebih lambat dari kompilasi templat waktu C ++.

Dan ketika Anda menerima semua optimasi waktu kompilasi lainnya yang disebutkan oleh begitu banyak orang lain, serta kurangnya keamanan yang memang, berarti, lebih cepat ...

Saya akan mengatakan C ++ adalah pilihan yang jelas dalam hal kecepatan mentah dan konsumsi memori minimum. Tetapi ini juga berarti lebih banyak waktu mengembangkan kode dan memastikan Anda tidak membocorkan memori atau menyebabkan pengecualian null pointer.

Putusan:

• C #: Pengembangan lebih cepat, lari lebih lambat

• C ++: Pengembangan lambat, lari lebih cepat.

Itu benar-benar tergantung pada apa yang ingin Anda capai dalam kode Anda. Saya pernah mendengar bahwa itu hanya legenda urban bahwa ada perbedaan kinerja antara VB.NET, C # dan C ++ yang dikelola. Namun, saya telah menemukan, setidaknya dalam perbandingan string, yang berhasil C ++ mengalahkan celana dari C #, yang pada gilirannya mengalahkan celana dari VB.NET.

Saya tidak pernah melakukan perbandingan lengkap dalam kompleksitas algoritmik antara bahasa. Saya juga hanya menggunakan pengaturan default di masing-masing bahasa. Di VB.NET saya menggunakan pengaturan untuk meminta deklarasi variabel, dll. Berikut adalah kode yang saya gunakan untuk C ++ terkelola: (Seperti yang Anda lihat, kode ini cukup sederhana). Saya menjalankan hal yang sama dalam bahasa lain di Visual Studio 2013 dengan .NET 4.6.2.

#include "stdafx.h"

using namespace System;
using namespace System::Diagnostics;

bool EqualMe(String^ first, String^ second)
{
    return first->Equals(second);
}
int main(array<String ^> ^args)
{
    Stopwatch^ sw = gcnew Stopwatch();
    sw->Start();
    for (int i = 0; i < 100000; i++)
    {
        EqualMe(L"one", L"two");
    }
    sw->Stop();
    Console::WriteLine(sw->ElapsedTicks);
    return 0;
}

Ada beberapa perbedaan utama antara C # dan C ++ pada aspek kinerja:

• C # berbasis GC / heap. Alokasi dan GC itu sendiri adalah overhead sebagai bukan lokalitas dari akses memori
• Pengoptimal C ++ telah menjadi sangat baik selama bertahun-tahun. Kompiler JIT tidak dapat mencapai level yang sama karena mereka hanya memiliki waktu kompilasi terbatas dan tidak melihat lingkup global

Selain itu kompetensi programmer juga berperan. Saya telah melihat kode C ++ yang buruk di mana kelas mana dilewatkan oleh nilai sebagai argumen di semua tempat. Anda benar-benar dapat membuat kinerja lebih buruk di C ++ jika Anda tidak tahu apa yang Anda lakukan.

> Bagaimanapun juga, jawabannya harus ada di suatu tempat, bukan? :)

Umm, tidak.

Seperti yang dicatat beberapa balasan, pertanyaan tersebut tidak ditentukan dengan cara yang mengundang pertanyaan sebagai jawaban, bukan jawaban. Untuk mengambil hanya satu cara:

• pertanyaannya mengonfigurasikan bahasa dengan implementasi bahasa - program C ini lebih lambat 2.194 kali dan 1.17 kali lebih cepat daripada program C # ini - kami harus bertanya kepada Anda: Implementasi bahasa mana?

Lalu program apa? Mesin yang mana? OS yang mana? Kumpulan data yang mana?

Terinspirasi oleh ini, saya melakukan tes cepat dengan 60 persen instruksi umum yang dibutuhkan di sebagian besar program.

Berikut kode C #:

for (int i=0; i<1000; i++)
{
    StreamReader str = new StreamReader("file.csv");
    StreamWriter stw = new StreamWriter("examp.csv");
    string strL = "";
    while((strL = str.ReadLine()) != null)
    {
        ArrayList al = new ArrayList();
        string[] strline = strL.Split(',');
        al.AddRange(strline);
        foreach(string str1 in strline)
        {
            stw.Write(str1 + ",");
        }
        stw.Write("\n");
    }
    str.Close();
    stw.Close();
}

Array string dan arraylist digunakan dengan sengaja untuk memasukkan instruksi tersebut.

Berikut kode c ++:

for (int i = 0; i<1000; i++)
{
    std::fstream file("file.csv", ios::in);
    if (!file.is_open())
    {
        std::cout << "File not found!\n";
        return 1;
    }

    ofstream myfile;
    myfile.open ("example.txt");
    std::string csvLine;

    while (std::getline(file, csvLine))
    {
        std::istringstream csvStream(csvLine);
        std::vector csvColumn;
        std::string csvElement;

        while( std::getline(csvStream, csvElement, ‘,’) )
        {
            csvColumn.push_back(csvElement);
        }

        for (std::vector::iterator j = csvColumn.begin(); j != csvColumn.end(); ++j)
        {
            myfile << *j << ", ";
        }

        csvColumn.clear();
        csvElement.clear();
        csvLine.clear();
        myfile << "\n";
    }
    myfile.close();
    file.close();
}

Ukuran file input yang saya gunakan adalah 40 KB.

Dan inilah hasilnya -

• Kode C ++ dijalankan dalam 9 detik.
• Kode C #: 4 detik !!!

Oh, tapi ini di Linux ... Dengan C # berjalan di Mono ... Dan C ++ dengan g ++.

OK, inilah yang saya dapatkan di Windows - Visual Studio 2003 :

• Kode C # dijalankan dalam 9 detik.
• Kode C ++ - 370 detik yang mengerikan !!!