Mengapa beberapa bahasa pemrograman "lebih cepat" atau "lebih lambat" daripada yang lain?

82

Saya telah memperhatikan bahwa beberapa aplikasi atau algoritma yang dibangun pada bahasa pemrograman, katakanlah C ++ / Rust berjalan lebih cepat atau lebih cepat daripada yang dibangun di atas, Java / Node.js, berjalan pada mesin yang sama. Saya punya beberapa pertanyaan tentang ini:

  1. Mengapa ini terjadi?
  2. Apa yang mengatur "kecepatan" bahasa pemrograman?
  3. Apakah ini ada hubungannya dengan manajemen memori?

Saya benar-benar akan menghargai jika seseorang memecahkan ini untuk saya.

evil_potato
sumber
18
Perhatikan bahwa untuk JVM dan CLR khususnya, penelitian ekstensif telah dilakukan untuk mengoptimalkan VM, dan mereka dapat mengungguli yang dikompilasi C ++ dalam banyak keadaan - tetapi mudah untuk melakukan pembandingan naif yang salah.
chrylis -on strike-
26
Yang mengatakan, bundling Java dan segala sesuatu yang berhubungan dengan Javascript bersama adalah menghina.
Raphael
5
Saya terpecah antara menutup ini karena terlalu luas (buku teks dapat ditulis tentang topik yang relevan!) Atau duplikat . Pemungutan suara komunitas!
Raphael
4
pertanyaan ini juga sangat mirip apa yang menentukan kecepatan bahasa pemrograman
vzn

Jawaban:

96

Dalam desain dan implementasi bahasa pemrograman, ada sejumlah besar pilihan yang dapat memengaruhi kinerja. Saya hanya akan menyebutkan beberapa.

Setiap bahasa pada akhirnya harus dijalankan dengan mengeksekusi kode mesin. Bahasa "dikompilasi" seperti C ++ diuraikan, didekodekan, dan diterjemahkan ke kode mesin hanya sekali, pada waktu kompilasi. Bahasa "ditafsirkan", jika diterapkan secara langsung, diterjemahkan pada saat runtime, pada setiap langkah, setiap waktu. Artinya, setiap kali kita menjalankan pernyataan, intepreter harus memeriksa apakah itu if-then-else, atau assignment, dll. Dan bertindak sesuai dengan itu. Ini berarti bahwa jika kita mengulang 100 kali, kita mendekode kode yang sama 100 kali, membuang-buang waktu. Untungnya, interpreter sering mengoptimalkan ini melalui misalnya sistem kompilasi just-in-time. (Lebih tepatnya, tidak ada yang namanya bahasa "dikompilasi" atau "ditafsirkan" - itu adalah properti dari implementasi, bukan bahasa. Namun,

Kompiler / juru bahasa yang berbeda melakukan optimasi yang berbeda pula.

Jika bahasa memiliki manajemen memori otomatis, implementasinya harus melakukan pengumpulan sampah. Ini memiliki biaya runtime, tetapi membebaskan programmer dari tugas yang rawan kesalahan.

Sebuah bahasa mungkin lebih dekat ke mesin, memungkinkan programmer ahli untuk mengoptimalkan semuanya secara mikro dan memeras lebih banyak kinerja dari CPU. Namun, dapat diperdebatkan apakah ini benar-benar bermanfaat dalam praktik, karena sebagian besar programmer tidak benar-benar mengoptimalkan mikro, dan seringkali bahasa tingkat yang lebih tinggi dapat dioptimalkan oleh kompiler lebih baik daripada apa yang akan dilakukan oleh programmer rata-rata. (Namun, kadang-kadang menjadi lebih jauh dari mesin mungkin memiliki manfaatnya juga! Misalnya, Haskell sangat tinggi, tetapi berkat pilihan desainnya, fitur benang hijau yang sangat ringan.)

Pengecekan tipe statis juga dapat membantu dalam optimasi. Dalam dinamis mengetik, bahasa ditafsirkan, setiap kali satu menghitung x - y, penafsir sering harus memeriksa apakah kedua x,yadalah nomor dan (misalnya) meningkatkan pengecualian sebaliknya. Pemeriksaan ini dapat dilewati jika jenis sudah diperiksa pada waktu kompilasi.

Beberapa bahasa selalu melaporkan kesalahan runtime dengan cara yang waras. Jika Anda menulis a[100]di Java di mana ahanya memiliki 20 elemen, Anda mendapatkan pengecualian runtime. Dalam C, itu akan menyebabkan perilaku yang tidak terdefinisi, yang berarti bahwa program mungkin macet, menimpa beberapa data acak dalam memori, atau bahkan benar - benar melakukan hal lain (standar ISO C tidak membatasi apa pun). Ini membutuhkan pemeriksaan runtime, tetapi memberikan semantik yang jauh lebih baik untuk programmer.

Namun, perlu diingat bahwa, ketika mengevaluasi suatu bahasa, kinerja bukanlah segalanya. Jangan terobsesi dengan hal itu. Ini adalah perangkap umum untuk mencoba mengoptimalkan semuanya secara mikro, namun gagal menemukan bahwa algoritma / struktur data yang tidak efisien sedang digunakan. Knuth pernah berkata "optimasi prematur adalah akar dari semua kejahatan".

Jangan meremehkan betapa sulitnya menulis program dengan benar . Seringkali, bisa lebih baik untuk memilih bahasa "lebih lambat" yang memiliki semantik yang lebih ramah terhadap manusia. Lebih lanjut, jika ada beberapa bagian penting kinerja spesifik, mereka selalu dapat diimplementasikan dalam bahasa lain. Sama seperti referensi, dalam kontes pemrograman ICFP 2016 , ini adalah bahasa yang digunakan oleh pemenang:

1   700327  Unagi                       Java,C++,C#,PHP,Haskell
2   268752  天羽々斬                     C++, Ruby, Python, Haskell, Java, JavaScript
3   243456  Cult of the Bound Variable  C++, Standard ML, Python

Tak satu pun dari mereka menggunakan satu bahasa.

chi
sumber
81
Satu versi dari keseluruhan kutipan dari Knuth : "Programer menghabiskan banyak waktu memikirkan, atau mengkhawatirkan, kecepatan bagian nonkritis dari program mereka, dan upaya efisiensi ini sebenarnya memiliki dampak negatif yang kuat ketika debugging dan pemeliharaan dipertimbangkan. Kita harus melupakan efisiensi kecil, katakanlah sekitar 97% dari waktu: optimasi prematur adalah akar dari semua kejahatan. Namun kita tidak boleh melewatkan peluang kita dalam 3% kritis itu. "
Derek Elkins
6
Juga beberapa bahasa menjamin hal-hal yang tampaknya tidak bersalah yang dapat mempengaruhi kemampuan kompiler untuk mengoptimalkan, lihat aliasing ketat dalam C ++ vs. FORTRAN
PlasmaHH
9
Bergabung jadi saya bisa mengunggulkan komentar oleh @DerekElkins. Terlalu sering konteks kutipan itu hilang, kadang-kadang bahkan mengarah pada kesimpulan bahwa itu menganjurkan bahwa semua optimisasi itu jahat.
pipa
9
@DerekElkins Ironisnya, Anda melewatkan bagian yang paling penting: dua kalimat segera menyusul. "Seorang programmer yang baik tidak akan terbuai oleh kepuasan dengan alasan seperti itu, dia akan bijaksana untuk melihat dengan hati-hati pada kode kritis; tetapi hanya setelah kode itu telah diidentifikasi. Seringkali kesalahan untuk membuat penilaian apriori tentang bagian mana dari suatu Program sangat penting, karena pengalaman universal programmer yang telah menggunakan alat pengukuran adalah bahwa dugaan intuitif mereka gagal. " PDF p268
8bittree
9
@DerekElkins Untuk lebih jelasnya, saya tidak ingin menaruh kata-kata di mulut Anda mengatakan Anda mengklaim ini, tetapi terlalu sering saya menemukan orang-orang hanya menambahkan sedikit ke kutipan dasar, dan berpikir bahwa Knuth menganjurkan untuk optimasi prematur 3 % kali, ketika artikel lengkap membuatnya jelas dia selalu menentang optimasi prematur, hampir selalu menentang optimasi kecil, tetapi menganjurkan untuk optimasi kecil di bagian-bagian yang diukur sebagai kritis.
8bittree
19

Apa yang mengatur "kecepatan" bahasa pemrograman?

Tidak ada yang namanya "kecepatan" dari bahasa pemrograman. Hanya ada kecepatan program tertentu yang ditulis oleh progammer tertentu yang dieksekusi oleh versi tertentu dari implementasi tertentu dari mesin eksekusi tertentu yang berjalan dalam lingkungan tertentu.

Mungkin ada perbedaan kinerja yang sangat besar dalam menjalankan kode yang sama yang ditulis dalam bahasa yang sama pada mesin yang sama menggunakan implementasi yang berbeda. Atau bahkan menggunakan versi berbeda dari implementasi yang sama. Misalnya, menjalankan benchmark ECMAScript yang sama persis pada mesin yang sama persis menggunakan versi SpiderMonkey dari 10 tahun yang lalu vs versi dari tahun ini mungkin akan menghasilkan peningkatan kinerja di mana saja antara 2 × –5 ×, bahkan mungkin 10 ×. Apakah itu berarti ECMAScript 2x lebih cepat dari ECMAScript, karena menjalankan program yang sama pada mesin yang sama 2x lebih cepat dengan implementasi yang lebih baru? Itu tidak masuk akal.

Apakah ini ada hubungannya dengan manajemen memori?

Tidak juga.

Mengapa ini terjadi?

Sumber daya. Uang. Microsoft mungkin mempekerjakan lebih banyak orang membuat kopi untuk programmer kompiler mereka daripada seluruh komunitas PHP, Ruby, dan Python digabungkan memiliki orang yang bekerja pada VM mereka.

Untuk lebih atau kurang fitur apa saja dari bahasa pemrograman yang memengaruhi kinerja dalam beberapa cara, ada juga solusinya. Misalnya, C (saya menggunakan C di sini sebagai pengganti untuk kelas bahasa yang serupa, beberapa di antaranya bahkan ada sebelum C) tidak aman untuk memori, sehingga beberapa program C yang berjalan pada saat yang sama dapat menginjak-injak memori masing-masing. Jadi, kami menciptakan memori virtual, dan membuat semua program C melewati lapisan tipuan sehingga mereka dapat berpura-pura mereka adalah satu-satunya yang berjalan pada mesin. Namun, itu lambat, dan karenanya, kami menciptakan MMU, dan mengimplementasikan memori virtual dalam perangkat keras untuk mempercepatnya.

Tapi! Bahasa memori-aman tidak membutuhkan semua itu! Memiliki memori virtual tidak membantu mereka sedikit pun. Sebenarnya, ini lebih buruk: tidak hanya memori virtual tidak membantu bahasa yang aman-memori, memori virtual, bahkan ketika diimplementasikan dalam perangkat keras, masih berdampak pada kinerja. Hal ini dapat sangat merusak kinerja pengumpul sampah (yang merupakan jumlah signifikan dari implementasi bahasa yang menggunakan memori aman).

Contoh lain: CPU modern mainstream umum menggunakan trik canggih untuk mengurangi frekuensi cache yang hilang. Banyak dari trik-trik itu sama dengan mencoba memprediksi kode apa yang akan dieksekusi dan memori apa yang akan dibutuhkan di masa depan. Namun, untuk bahasa dengan tingkat polimorfisme runtime yang tinggi (misalnya bahasa OO), sangat sulit untuk memprediksi pola akses tersebut.

Tapi, ada cara lain: total biaya kesalahan cache adalah jumlah kesalahan cache dikalikan dengan biaya miss cache individu. CPU arus utama mencoba untuk mengurangi jumlah kesalahan, tetapi bagaimana jika Anda dapat mengurangi biaya kehilangan individu?

CPU Azul Vega-3 dirancang khusus untuk menjalankan JVM tervirtualisasi, dan memiliki MMU yang sangat kuat dengan beberapa instruksi khusus untuk membantu pengumpulan sampah dan lolos dari deteksi (ekuivalen dinamis dengan analisis pelarian statis) dan pengontrol memori yang kuat, dan seluruh sistem masih bisa membuat kemajuan dengan lebih dari 20000 cache cache yang beredar dalam penerbangan. Sayangnya, seperti kebanyakan CPU khusus bahasa, desainnya hanya menghabiskan dan memaksa oleh "raksasa" Intel, AMD, IBM, dan sejenisnya.

Arsitektur CPU hanyalah salah satu contoh yang berdampak pada seberapa mudah atau sulitnya untuk memiliki implementasi bahasa yang berkinerja tinggi. Bahasa seperti C, C ++, D, Rust yang cocok untuk model pemrograman CPU arus utama modern akan lebih mudah dibuat lebih cepat daripada bahasa yang harus "berkelahi" dan mengelak dari CPU, seperti Java, ECMAScript, Python, Ruby , PHP.

Sungguh, itu semua masalah uang. Jika Anda menghabiskan jumlah uang yang sama untuk mengembangkan algoritme kinerja tinggi dalam ECMAScript, implementasi ECMAScript kinerja tinggi, sistem operasi berkinerja tinggi yang dirancang untuk ECMAScript, CPU berkinerja tinggi yang dirancang untuk ECMAScript sebagaimana telah dihabiskan selama yang terakhir beberapa dekade untuk membuat bahasa mirip-C berjalan cepat, maka Anda mungkin akan melihat kinerja yang sama. Hanya saja, pada saat ini, lebih banyak uang telah dihabiskan untuk membuat bahasa seperti C lebih cepat daripada membuat bahasa seperti ECMAScript, dan asumsi bahasa seperti C dimasukkan ke dalam seluruh tumpukan mulai dari MMU dan CPU hingga sistem operasi dan sistem memori virtual hingga pustaka dan kerangka kerja.

Secara pribadi, saya paling akrab dengan Ruby (yang umumnya dianggap sebagai "bahasa lambat"), jadi saya akan memberikan dua contoh: Hashkelas (salah satu struktur data pusat di Ruby, kamus kunci-nilai) di Rubinius Implementasi Ruby ditulis dalam 100% Ruby murni, dan memiliki kinerja yang hampir sama denganHashkelas di YARV (implementasi yang paling banyak digunakan), yang ditulis dalam C. Dan ada perpustakaan manipulasi gambar yang ditulis sebagai ekstensi C untuk YARV, yang juga memiliki Ruby (versi fallback) "lambat" murni untuk implementasi yang tidak dapat mendukung C yang menggunakan banyak trik Ruby yang sangat dinamis dan reflektif; cabang eksperimental JRuby, memanfaatkan kerangka kerja juru bahasa Truffle AST dan kerangka kerja kompilasi Graal JIT oleh Oracle Labs, dapat mengeksekusi Ruby murni "versi mundur" secepat YARV dapat menjalankan versi C yang dioptimalkan dengan sangat tinggi. Ini hanya (well, apapun kecuali) dicapai oleh beberapa orang yang sangat pintar melakukan hal-hal yang sangat pintar dengan optimasi runtime dinamis, kompilasi JIT, dan evaluasi parsial.

Jörg W Mittag
sumber
4
Meskipun secara teknis bahasa tidak inheren cepat, beberapa bahasa memiliki fokus yang lebih besar pada memungkinkan programmer untuk membuat kode cepat. C terutama dioptimalkan untuk CPU daripada sebaliknya. Sebagai contoh, C memilih ukuran tetap intuntuk alasan kinerja, terlepas dari kenyataan bahwa bilangan bulat tak terikat seperti yang digunakan oleh Python jauh lebih alami secara matematis. Menerapkan bilangan bulat tanpa batas dalam perangkat keras tidak akan secepat bilangan bulat ukuran tetap. Bahasa yang mencoba untuk menyembunyikan detail implementasi membutuhkan optimisasi yang kompleks untuk mendekati implementasi C naif.
gmatht
1
C memiliki sejarah - diciptakan untuk membuat sistem yang ditulis dalam bahasa assembly portabel untuk sistem lain. Jadi tujuan awalnya adalah untuk menyediakan "assembler portabel" untuk Unix, dan dirancang dengan sangat baik. Itu melakukannya dengan baik dari 1980-1995-ish yang memiliki massa kritis ketika Windows 95 muncul.
Thorbjørn Ravn Andersen
1
Saya tidak setuju dengan komentar tentang sumber daya. Bukan jumlah orang dalam tim yang penting, melainkan tingkat keterampilan orang-orang terbaik di tim.
Michael Kay
"Microsoft mungkin mempekerjakan lebih banyak orang yang membuat kopi untuk programmer kompiler mereka daripada seluruh komunitas PHP, Ruby, dan Python yang digabung memiliki orang yang bekerja pada VM mereka" Saya kira itu tergantung pada seberapa jauh Anda bersedia untuk memperluas istilah "programmer kompiler" dan berapa banyak Anda termasuk dengan itu (Microsoft mengembangkan banyak kompiler). Sebagai contoh, hanya tim penyusun VS C ++ AFAIK yang relatif kecil.
Cubic
7

Secara teoritis, jika Anda menulis kode yang melakukan hal yang persis sama dalam dua bahasa dan mengkompilasi keduanya menggunakan kompiler "sempurna", kinerja keduanya harus sama.

Dalam praktiknya, ada beberapa alasan mengapa kinerja akan berbeda:

  1. Beberapa bahasa lebih sulit untuk dioptimalkan.

    Ini termasuk terutama fitur yang membuat kode lebih dinamis (pengetikan dinamis, metode virtual, fungsi pointer), tetapi juga untuk pengumpulan sampah misalnya.

    Ada berbagai cara untuk membuat kode menggunakan fitur-fitur tersebut dengan cepat, tetapi biasanya masih berakhir setidaknya agak lebih lambat daripada tanpa menggunakannya.

  2. Beberapa implementasi bahasa harus melakukan kompilasi saat runtime.

    Ini berlaku terutama untuk bahasa dengan mesin virtual (seperti Java) dan bahasa yang mengeksekusi kode sumber, tanpa langkah menengah untuk biner (seperti JavaScript).

    Implementasi bahasa seperti itu harus melakukan lebih banyak pekerjaan pada saat runtime, yang mempengaruhi kinerja, terutama waktu startup / kinerja segera setelah startup.

  3. Implementasi bahasa sengaja menghabiskan lebih sedikit waktu untuk optimasi daripada yang mereka bisa.

    Semua kompiler peduli tentang kinerja kompiler itu sendiri, bukan hanya dari kode yang dihasilkan. Ini terutama penting untuk kompiler runtime (kompiler JIT), di mana waktu yang terlalu lama untuk dikompilasi memperlambat eksekusi aplikasi. Tetapi ini berlaku untuk kompiler yang lebih dulu, seperti yang untuk C ++ juga. Misalnya alokasi register adalah masalah NP-complete, jadi tidak realistis untuk menyelesaikannya dengan sempurna dan sebaliknya heuristik yang mengeksekusi dalam waktu yang wajar digunakan.

  4. Perbedaan idiom dalam berbagai bahasa.

    Kode yang ditulis dengan gaya umum untuk bahasa tertentu (kode idiomatik) menggunakan perpustakaan umum dapat menghasilkan perbedaan dalam kinerja, karena kode idiomatik tersebut berperilaku berbeda secara halus dalam setiap bahasa.

    Sebagai contoh, perhatikan vector[i]di C ++, list[i]di C # dan list.get(i)di Jawa. Kode C ++ kemungkinan tidak melakukan pengecekan jangkauan dan tidak melakukan panggilan virtual, kode C # melakukan pengecekan jangkauan, tetapi tidak ada panggilan virtual dan kode Java melakukan pengecekan jangkauan dan ini adalah panggilan virtual. Ketiga bahasa ini mendukung metode virtual dan non-virtual dan baik C ++ maupun C # dapat menyertakan pengecekan rentang atau menghindarinya saat mengakses array yang mendasarinya. Tetapi pustaka standar dari bahasa-bahasa ini memutuskan untuk menulis fungsi-fungsi yang setara ini secara berbeda, dan, sebagai konsekuensinya, kinerjanya akan berbeda.

  5. Beberapa kompiler mungkin kehilangan beberapa optimasi.

    Penulis kompiler memiliki sumber daya yang terbatas, sehingga mereka tidak dapat menerapkan setiap optimasi yang mungkin, bahkan mengabaikan masalah lainnya. Dan sumber daya yang mereka miliki mungkin terfokus pada satu bidang optimasi lebih dari yang lain. Sebagai akibatnya, kode yang ditulis dalam bahasa yang berbeda dapat memiliki kinerja yang berbeda karena perbedaan dalam kompiler mereka, bahkan jika tidak ada alasan mendasar mengapa satu bahasa harus lebih cepat atau bahkan lebih mudah dioptimalkan daripada yang lain.

svick
sumber
Beberapa bahasa tidak memiliki kompiler. Untuk beberapa bahasa, tidak ada kompiler ( referensi ).
Raphael
3
Untuk beberapa bahasa, tidak mungkin ada kompiler statis . Kompilasi dinamis tidak terpengaruh oleh ketidakpastian sifat statis.
Jörg W Mittag
Jika bahasa cukup berbeda, mereka tidak memiliki "kode yang melakukan hal yang persis sama". Mereka mungkin memiliki kode yang menghasilkan output yang sama atau perilaku yang dapat diamati pengguna, yang bukan merupakan hal yang sama. Jadi saya tidak setuju dengan premis Anda.
einpoklum - mengembalikan Monica
@einpoklum Saya tidak melihat perbedaannya. Dengan beberapa pengecualian (seperti sinkronisasi threading), yang saya pikir tidak menarik di sini, spesifikasi bahasa biasanya memungkinkan optimasi apa pun yang menjaga perilaku yang dapat diamati. Perilaku seperti apa yang ada dalam pikiran Anda yang tidak dapat diamati oleh pengguna, tetapi tidak dapat dioptimalkan?
svick
Secara teoritis, setiap bahasa yang ditafsirkan dapat "dikompilasi" dengan menghasilkan file EXE yang terdiri dari penerjemah + kode sumber program.
dan04
1

Ini adalah pertanyaan yang sangat umum, tetapi dalam kasus Anda jawabannya bisa sederhana. C ++ mengkompilasi ke kode mesin, di mana Java mengkompilasi ke kode byte Java, yang kemudian dijalankan dari mesin virtual Java (meskipun ada juga kompilasi just-in-time, yang selanjutnya mengkompilasi kode byte Java ke kode mesin asli). Perbedaan lainnya dapat berupa pengumpulan sampah, yang merupakan layanan yang hanya disediakan oleh Java.

Yuval Filmus
sumber
2
Ini adalah jawaban yang terlalu sederhana. Ada pengaturan di mana Java lebih cepat.
Raphael
4
Ada juga implementasi Java yang mengkompilasi ke kode mesin dan menafsirkan implementasi C ++. Dan apa itu "kode mesin", jika saya memiliki CPU picoJava yang mengeksekusi bytecode JVM secara asli, dan saya memiliki interpreter JPC x86 yang berjalan pada JVM, lalu apa yang membuat kode objek x86 "kode mesin" dan bytecode JVM tidak?
Jörg W Mittag
2
Nitpick: Tidak hanya Java menyediakan pengumpulan sampah ... dan bahkan jika Anda hanya mempertimbangkan C ++ dan Java, beberapa program kerangka kerja / pustaka C ++ memiliki fasilitas pengumpulan sampah.
einpoklum - mengembalikan Monica
Mengkompilasi ke kode mesin asli biasanya meningkatkan kinerja. Namun, dalam beberapa kasus terbatas, juru bahasa berkualitas tinggi dapat mengalahkan kompiler just-in-time yang naif.
DepressedDaniel
@ JörgWMittag Triknya adalah mengkompilasi ke kode mesin asli - kode mesin yang dimengerti oleh prosesor host - dan kemudian langsung melompat ke kode yang dipanggil sehingga dapat dieksekusi tanpa interpretasi. Ini akan menjadi x86 pada chip x86 dan bytecode JVM pada CPU picoJava.
DepressedDaniel
-5

Pertanyaan Anda terlalu umum, jadi saya khawatir saya tidak bisa memberikan jawaban yang tepat yang Anda butuhkan.

Untuk penjelasan terbaik saya, mari kita lihat platform C ++ dan .Net.

C + +, sangat dekat dengan kode mesin dan salah satu pemrograman yang disukai dalam waktu yang lebih lama (seperti lebih dari 10 tahun yang lalu?) Karena kinerja. Tidak banyak sumber daya yang dibutuhkan untuk mengembangkan dan menjalankan program C ++ bahkan dengan IDE, mereka dianggap sangat ringan dan sangat cepat. Anda juga dapat menulis kode C ++ di konsol dan mengembangkan game dari sana. Dalam hal memori dan sumber daya, saya lupa kira-kira berapa banyak kapasitas yang dibutuhkan dalam komputer tetapi kapasitasnya adalah sesuatu yang tidak dapat Anda bandingkan dengan generasi saat ini dalam bahasa pemrograman.

Sekarang mari kita lihat. Net. Prasyarat untuk melakukan pengembangan. Net adalah salah satu IDE raksasa yang terdiri dari tidak hanya satu jenis bahasa pemrograman. Bahkan jika Anda hanya ingin pengembang dalam katakanlah C #, IDE itu sendiri akan mencakup banyak platform pemrograman secara default seperti J #, VB, ponsel dan lain-lain secara default. Kecuali Anda menginstal kustom dan hanya menginstal persis apa yang Anda inginkan, asalkan Anda cukup berpengalaman untuk bermain dengan instalasi IDE.

Selain menginstal perangkat lunak IDE itu sendiri. Net juga dilengkapi dengan perpustakaan dan kerangka kerja berkapasitas besar untuk tujuan kemudahan akses ke segala jenis platform yang dibutuhkan pengembang DAN tidak perlu.

Berkembang di .Net bisa menjadi pengalaman yang menyenangkan karena banyak fungsi dan komponen umum tersedia secara default. Anda dapat menyeret-dan-jatuhkan dan menggunakan banyak metode validasi, membaca file, akses database, dan banyak lagi di IDE.

Akibatnya, ini merupakan pertukaran antara sumber daya komputer dan kecepatan pengembangan. Perpustakaan dan kerangka kerja tersebut membutuhkan memori dan sumber daya. Saat Anda menjalankan program dalam .Net IDE, mungkin perlu banyak waktu untuk mencoba mengkompilasi pustaka, komponen, dan semua file Anda. Dan ketika Anda melakukan debugging, komputer Anda membutuhkan banyak sumber daya untuk mengelola proses debugging di IDE Anda.

Biasanya, untuk melakukan pengembangan. Net, Anda memerlukan komputer yang bagus dengan beberapa Ram dan prosesor. Jika tidak, Anda mungkin tidak memprogram sama sekali. Dalam aspek ini, platform C ++ jauh lebih baik daripada .Net. Meskipun Anda masih membutuhkan komputer yang bagus, tetapi kapasitas tidak akan terlalu menjadi masalah dibandingkan dengan .Net.

Semoga jawaban saya dapat membantu dengan pertanyaan Anda. Beri tahu saya jika Anda ingin tahu lebih banyak.

SUNTING:

Hanya klarifikasi ke poin utama saya, saya terutama menjawab pertanyaan "Apa yang mengatur kecepatan pemrograman".

Dalam sudut pandang IDE, menggunakan bahasa C ++ atau .Net di IDE relatif tidak mempengaruhi kecepatan penulisan kode, tetapi akan mempengaruhi kecepatan pengembangan karena kompiler Visual Studio membutuhkan waktu lebih lama untuk menjalankan program, tetapi C ++ IDE jauh lebih ringan dan mengkonsumsi lebih sedikit sumber daya komputer. Jadi dalam jangka panjang, Anda dapat melakukan pemrograman lebih cepat dengan tipe C ++ IDE dibandingkan dengan .Net IDE yang sangat bergantung pada pustaka dan framework. Jika Anda mengambil dalam jumlah waktu menunggu IDE untuk memulai, mengkompilasi, menjalankan program dan lain-lain, itu akan mempengaruhi kecepatan pemrograman. Kecuali "kecepatan pemrograman" sebenarnya hanya fokus pada "kecepatan menulis kode".

Jumlah perpustakaan dan kerangka kerja di Visual Studio juga mengkonsumsi kapasitas komputer. Saya tidak yakin apakah ini menjawab pertanyaan "manajemen memori", tapi saya hanya ingin menunjukkan bahwa Visual Studio IDE dapat mengambil banyak sumber daya saat menjalankannya, dan dengan demikian memperlambat keseluruhan "kecepatan pemrograman". Tentu saja, ini tidak ada hubungannya dengan "kecepatan penulisan kode".

Seperti yang mungkin sudah Anda duga, saya tidak tahu terlalu banyak tentang C ++ karena saya hanya menggunakannya sebagai contoh, poin utama saya adalah tentang tipe Visual Studio dari IDE berat yang menggunakan sumber daya komputer.

Jika saya mendapat ide dan sama sekali tidak menjawab pertanyaan pembuka utas, mohon maaf untuk posting lama. Tapi saya akan menyarankan pemula thread untuk membuat pertanyaan yang jelas dan bertanya apa yang dia perlu tahu tentang "lebih cepat" dan "lebih lambat"

Koo SengSeng
sumber
6
Sebagai catatan, pengembangan .NET hanya membutuhkan .NET SDK (dan, untuk eksekusi, runtime .NET itu sendiri). Anda dapat menggunakan editor teks biasa dan memanggil kompiler dari baris perintah. IDE (saya berasumsi Anda mengacu pada Visual Studio) TIDAK diperlukan, meskipun pasti membantu dengan proyek yang cukup besar (Intellisense, debugger, dll.). Ada juga IDE yang lebih ringan seperti SharpDevelop dengan lebih sedikit lonceng dan peluit.
MetalMikester
16
Anda tentu dapat mengembangkan. Net tanpa IDE. Tapi saya tidak melihat bagaimana IDE relevan dengan kecepatan kode yang ditulis dalam bahasa.
svick
8
@MetalMikester: Dan tentu saja, Visual Studio adalah IDE untuk pengembangan C ++ di Windows.
Jörg W Mittag
3
Dan mengkompilasi C ++ ke .Net code hanyalah sebuah saklar kompiler tunggal; jurang yang seharusnya adalah jembatan dengan satu klik mouse di visual studio.
MSalters
1
Saya sama sekali tidak yakin saya akan memanggil C ++ modern "sangat dekat dengan kode mesin". C asli, ya; itu dipahami sebagai assembler portabel dan tetap sangat dekat dengan itu (meskipun perpustakaan standar telah berkembang, dan berbagai kompiler menawarkan tambahan untuk bahasa yang tepat yang membawanya lebih jauh dari asalnya). C ++ Asli (C Dengan Kelas), mungkin; menulis ulang varian C yang mencakup kelas ke C murni tidak sulit, pada titik mana diskusi sebelumnya berlaku. Tapi C ++ modern, dengan templat, polimorfisme, dan yang lainnya di bawah Matahari? Itu hampir tidak "sangat dekat dengan kode mesin".
CVn