Apa yang menentukan "kecepatan" bahasa pemrograman?


38

Misalkan sebuah program ditulis dalam dua bahasa yang berbeda, biarkan mereka menjadi bahasa X dan bahasa Y, jika kompiler mereka menghasilkan kode byte yang sama, mengapa saya harus menggunakan bahasa X alih-alih bahasa Y? Apa yang mendefinisikan bahwa satu bahasa lebih cepat dari yang lain?

Saya bertanya ini karena sering Anda melihat orang mengatakan hal-hal seperti: "C adalah bahasa tercepat, ATS adalah bahasa secepat C". Saya sedang berusaha memahami definisi "cepat" untuk bahasa pemrograman.


21
Jika satu program lebih cepat dari yang lain, itu berarti mereka tidak dapat memiliki kode byte yang sama.
svick

5
Bahasa hanyalah gagasan yang digunakan untuk menulis program, sehingga Anda tidak dapat benar-benar berbicara tentang kecepatan suatu bahasa.
Juho

1
@ Raphael Saya merasa itu di luar topik, tidak jelas dan terlalu luas. Sementara topiknya lebih cocok untuk Rekayasa Perangkat Lunak , saya menduga itu akan ditutup sebagai "terlalu luas" di sana.
David Richerby

2
Implementasi samping, "kecepatan" adalah ambigu, ada kecepatan yang berbeda untuk melaksanakan, menyusun, melaksanakan, dan debugging, dan Anda biasanya akan perdagangan dari beberapa untuk orang lain (kalau tidak kita semua akan menggunakan satu bahasa pemrograman)
Nick T

Seperti di atas. Bahasa tidak menghasilkan kode byte yang sama. Beberapa bahasa lebih mudah diurai menjadi kode byte. Beberapa memiliki tingkat abstraksi yang lebih tinggi.
superluminary

Jawaban:


23

Ada banyak alasan yang dapat dipertimbangkan untuk memilih bahasa X daripada bahasa Y. Keterbacaan program, kemudahan pemrograman, portabilitas ke banyak platform, keberadaan lingkungan pemrograman yang baik dapat menjadi alasan tersebut. Namun, saya hanya akan mempertimbangkan kecepatan eksekusi seperti yang diminta dalam pertanyaan. Pertanyaannya tampaknya tidak mempertimbangkan, misalnya, kecepatan perkembangan.

Dua bahasa dapat dikompilasi dengan bytecode yang sama, tetapi itu tidak berarti bahwa kode yang sama akan diproduksi,

Sebenarnya bytecode hanya kode untuk mesin virtual tertentu. Itu memang memiliki keunggulan teknik, tetapi tidak memperkenalkan perbedaan mendasar dengan mengkompilasi secara langsung untuk harware tertentu. Jadi, Anda sebaiknya mempertimbangkan membandingkan dua bahasa yang dikompilasi untuk eksekusi langsung pada mesin yang sama.

Ini mengatakan, masalah kecepatan relatif dari bahasa adalah yang lama, dating kembali ke kompiler pertama.

Selama bertahun-tahun, pada masa-masa awal itu, profesional menganggap bahwa kode tulisan tangan lebih cepat daripada kode yang dikompilasi. Dengan kata lain, bahasa mesin dianggap lebih cepat daripada bahasa tingkat tinggi seperti Cobol atau Fortran. Dan itu, lebih cepat dan biasanya lebih kecil. Bahasa tingkat tinggi masih berkembang karena lebih mudah digunakan untuk banyak orang yang bukan ilmuwan komputer. Biaya menggunakan bahasa tingkat tinggi bahkan memiliki nama: rasio ekspansi, yang dapat menyangkut ukuran kode yang dihasilkan (masalah yang sangat penting pada masa itu) atau jumlah instruksi yang benar-benar dieksekusi. Konsep ini terutama eksperimental, tetapi rasionya lebih besar dari 1 pada awalnya, karena kompiler melakukan pekerjaan yang berpikiran sederhana menurut standar saat ini.

Dengan demikian bahasa mesin lebih cepat daripada mengatakan, Fortran.

Tentu saja, itu berubah selama bertahun-tahun, ketika kompiler menjadi lebih canggih, ke titik bahwa pemrograman dalam bahasa assembly sekarang sangat jarang. Untuk sebagian besar aplikasi, program bahasa assembly tidak mampu bersaing dengan kode yang dihasilkan dengan mengoptimalkan kompiler.

Ini menunjukkan bahwa satu masalah utama adalah kualitas kompiler yang tersedia untuk bahasa yang dipertimbangkan, kemampuan mereka untuk menganalisis kode sumber, dan untuk mengoptimalkannya.

Kemampuan ini mungkin bergantung pada beberapa perluasan fitur bahasa untuk menekankan sifat struktural dan matematika dari sumber untuk membuat pekerjaan lebih mudah bagi kompiler. Sebagai contoh, sebuah bahasa dapat memungkinkan penyertaan pernyataan tentang properti aljabar fungsi yang ditentukan pengguna, sehingga memungkinkan kompiler untuk menggunakan properti ini untuk tujuan optimasi.

Proses kompilasi mungkin lebih mudah, maka menghasilkan kode yang lebih baik, ketika paradigma pemrograman bahasa lebih dekat dengan fitur mesin yang akan mengintepret kode, apakah mesin nyata atau virtual.

Poin lainnya adalah apakah paradigma yang diterapkan dalam bahasa tertutup dengan jenis masalah yang diprogram. Diharapkan bahwa bahasa pemrograman yang dikhususkan untuk paradigma pemrograman tertentu akan mengkompilasi fitur yang sangat efisien terkait dengan paradigma itu. Oleh karena itu pilihan bahasa pemrograman dapat bergantung, untuk kejelasan dan kecepatan, pilihan bahasa pemrograman yang disesuaikan dengan jenis masalah yang diprogram.

Popularitas C untuk pemrograman sistem mungkin karena fakta bahwa C dekat dengan arsitektur mesin, dan pemrograman sistem secara langsung terkait dengan arsitektur itu juga.

Beberapa masalah lain akan lebih mudah diprogram, dengan eksekusi lebih cepat menggunakan pemrograman logika dan bahasa resolusi kendala .

Sistem reaktif yang kompleks dapat diprogram dengan sangat efisien dengan bahasa pemrograman sinkron khusus seperti Esterel yang mewujudkan pengetahuan yang sangat khusus tentang sistem tersebut dan menghasilkan kode yang sangat cepat.

Atau untuk mengambil contoh ekstrem, beberapa bahasa sangat khusus, seperti bahasa deskripsi sintaksis yang digunakan untuk memprogram parser. Sebuah parser generator tidak lain adalah sebuah compiler untuk bahasa tersebut. Tentu saja, ini bukan Turing lengkap, tetapi kompiler ini sangat bagus untuk spesialisasi mereka: menghasilkan program parsing yang efisien. Domain pengetahuan dibatasi, teknik pengoptimalan bisa sangat khusus dan disetel dengan sangat halus. Generator parser ini biasanya jauh lebih baik daripada yang bisa diperoleh dengan menulis kode dalam bahasa lain. Ada banyak bahasa yang sangat terspesialisasi dengan kompiler yang menghasilkan kode yang sangat baik dan cepat untuk kelas masalah yang terbatas.

Oleh karena itu, ketika menulis sistem yang besar, mungkin disarankan untuk tidak bergantung pada satu bahasa, tetapi untuk memilih bahasa terbaik untuk berbagai komponen sistem. Ini, tentu saja, menimbulkan masalah kompatibilitas.

Poin lain yang sering penting adalah keberadaan perpustakaan yang efisien untuk topik yang diprogram.

Akhirnya, kecepatan bukan satu-satunya kriteria dan mungkin bertentangan dengan kriteria lain seperti keamanan kode (untuk contoh sehubungan dengan input yang buruk, atau ketahanan terhadap kesalahan sistem), penggunaan memori, kemudahan pemrograman (meskipun kompatibilitas paradigma sebenarnya dapat membantu ), ukuran kode objek, kemampuan pemeliharaan program, dll.

Kecepatan tidak selalu merupakan parameter yang paling penting. Juga mungkin diperlukan kedok yang berbeda, seperti kompleksitas yang mungkin kompleksitas rata-rata atau kompleksitas kasus yang lebih buruk. Juga, dalam sistem besar seperti dalam program yang lebih kecil, ada bagian-bagian di mana kecepatan sangat penting, dan yang lain tidak penting. Dan tidak selalu mudah untuk menentukannya terlebih dahulu.


Terima kasih. Sesuatu seperti itu. Aku sedang mencari. Sulit untuk menemukan bahan untuk subjek. Ini cukup jelas.
Rodrigo Valente

@ RodrigoAraújoValente Terima kasih, Anda mungkin ingin melihat pertanyaan ini . Pandangan ekstremis adalah bahwa kompiler untuk bahasa L hanya dapat membundel penerjemah untuk L dengan kode sumber program, tanpa melakukan apa pun. Kemudian Anda dapat melakukan yang lebih baik dengan mencoba mengoptimalkan perhitungan bundel (evaluasi parsial). Semakin Anda mengoptimalkan dan semakin cepat bahasa Anda. Pertanyaannya kemudian: apa yang dapat membantu Anda mengoptimalkan? Jawaban dapat mencakup pengetahuan yang baik tentang bidang subjek khusus, bantuan dari programmer, analisis canggih, dll ...
babou

Dengan "bytecode yang sama" Saya menduga bahwa yang Anda maksud adalah " representasi yang dapat dieksekusi jenis yang sama ". Jelas executable yang identik akan berjalan pada kecepatan yang sama (dengan asumsi sistem eksekusi yang sama). (Saya mungkin akan melihat ini dari perspektif informasi / komunikasi. Secara teori , seorang programmer dapat mengetahui segala sesuatu tentang program dan perangkat keras sedangkan bahasa sering membatasi komunikasi (membatasi tranformasi apa yang diizinkan atau berguna) dan kompiler mungkin tidak tahu detail mikroarsitektur. Kompilasi dan pengembangan kompiler sangat cocok untuk pengembangan dan pelatihan ...
Paul A. Clayton

Ini kemudian masuk ke apa yang manusia umumnya pandai (misalnya, mengenali pola umum) versus apa komputer biasanya pandai (misalnya, pencatatan dan "aritmatika"). Selain itu, komunikasi informasi runtime seringkali lebih ramah komputer (pengoptimalan yang dipandu profil dapat mengatasi beberapa kekurangan informasi yang dikomunikasikan melalui bahasa pemrograman). Optimalisasi dinamis akan menjadi tidak praktis dengan programmer manusia ...
Paul A. Clayton

(walaupun hal yang sama dapat dikatakan untuk menulis semua perangkat lunak dalam perakitan oleh pemrogram terampil yang menargetkan perangkat keras tertentu, pada saat perangkat lunak dioptimalkan tidak hanya perangkat keras akan berubah tetapi perangkat lunak akan usang).)
Paul A. Clayton

16

Sementara semuanya pada akhirnya berjalan di CPU * , ada berbagai perbedaan antara bahasa yang berbeda. Berikut ini beberapa contohnya.

Bahasa ditafsirkan Beberapa bahasa yang ditafsirkan bukan dikompilasi , misalnya Python, Ruby dan Matlab. Itu berarti bahwa kode Python dan Ruby tidak dikompilasi ke kode mesin, melainkan ditafsirkan secara langsung. Dimungkinkan untuk mengkompilasi Python dan Ruby ke mesin virtual (lihat poin berikutnya). Lihat juga pertanyaan ini . Ditafsirkan pada umumnya lebih lambat dari kode yang dikompilasi karena berbagai alasan. Tidak hanya penafsiran itu sendiri lambat, juga lebih sulit untuk melakukan optimasi. Namun, jika kode Anda menghabiskan sebagian besar waktu pada fungsi perpustakaan (kasus Matlab), kinerja tidak akan berkurang.

Mesin virtual Beberapa bahasa dikompilasi menjadi bytecode , "kode mesin" yang ditemukan yang kemudian ditafsirkan. Contoh klasik adalah Java dan C #. Sementara bytecode dapat dikonversi ke kode mesin dengan cepat, kode tersebut mungkin masih berjalan lebih lambat. Dalam kasus Java, mesin virtual digunakan untuk portabilitas. Dalam kasus C #, mungkin ada masalah lain seperti keamanan.

Overhead Beberapa bahasa memperdagangkan efisiensi untuk keamanan. Misalnya, beberapa versi Pascal akan memeriksa apakah Anda tidak mengakses array di luar batas. Kode C # "dikelola", dan ini berbayar. Contoh umum lainnya adalah pengumpulan sampah, yang menghemat waktu untuk programmer tetapi tidak seefisien manajemen memori. Ada sumber overhead lain seperti infrastruktur untuk penanganan pengecualian atau untuk mendukung pemrograman berorientasi objek.

* Faktanya, saat ini sistem dengan kinerja tinggi juga menjalankan kode pada GPU dan bahkan pada FPGA.


Jadi, pada dasarnya jika saya butuh kinerja lebih tinggi saya harus menggunakan bahasa yang dikompilasi? Dan tentang paradigma? Ada alasan untuk memilih fungsional daripada oop, atau sebaliknya?
Rodrigo Valente

Komentar Anda tentang pengumpulan sampah agak sederhana. Tidak selalu dapat diputuskan secara statis ketika memori yang dialokasikan tidak lagi digunakan. Bahkan ketika decidable, mungkin sangat sulit untuk menentukan tanpa membuat kesalahan. Karenanya, GC kadang-kadang diperlukan dan sering kali lebih aman (seperti memeriksa batas array). Selain itu, dapat dikombinasikan dengan rilis eksplisit.
babou

@ RodrigoAraújoValente Tergantung. Kode jelek sering dikompilasi ke kode jelek. Mungkin kode yang dapat Anda tulis dengan Python sebenarnya lebih cepat daripada kode yang dapat Anda tulis dalam C.
Raphael

nit: seperti yang dijelaskan oleh pertanyaan yang Anda tautkan, python sebenarnya tidak diartikan "on-the-fly" :)
Eevee

Tidak ada bahasa yang Anda sebutkan di bagian yang ditafsirkan ditafsirkan dengan cepat. Python dikompilasi ke bytecode, Ruby dikompilasi ke AST, tapi saya percaya sekarang dikompilasi ke bytecode. Matlab, saya percaya sekarang sebenarnya JIT dikompilasi. Sebenarnya, saya tidak tahu implementasi bahasa non-niche yang menafsirkan hal-hal dengan cepat daripada setidaknya mengkompilasi ke beberapa jenis representasi mesin virtual.
Winston Ewert

5

Ada beberapa faktor untuk memilih X dan bukan Y, seperti

  • Kemudahan belajar
  • Kemudahan pemahaman
  • Kecepatan pengembangan
  • Membantu penegakan kode yang benar
  • Kinerja kode yang dikompilasi
  • Lingkungan platform yang didukung
  • Portabilitas
  • Cocok untuk keperluan

Beberapa bahasa cocok untuk mengembangkan proyek bisnis seperti C # atau Python, tetapi di sisi lain beberapa di antaranya bagus untuk pemrograman sistem seperti C ++.

Anda harus menentukan di bawah platform apa Anda akan bekerja dan aplikasi apa yang akan Anda buat.


1
Jadi, bagaimana saya menentukan kinerja kode yang dikompilasi? Itulah yang membuat saya melakukan pertanyaan ini.
Rodrigo Valente

6
Jawaban ini tentu saja memiliki saran yang bagus, tetapi saya gagal melihat bagaimana menjawab pertanyaan, yaitu tentang kecepatan sebagai faktor pilihan untuk suatu bahasa.
babou

@ RodrigoAraújoValente Mereka mungkin bahkan tidak akan dikompilasi kode (jika bahasa Anda ditafsirkan).
Raphael

1
Anda mungkin ingin menambahkan "Perpustakaan yang bagus" dan "Alat yang baik".
Raphael

@ RodrigoAraújoValente Anda menjalankannya dan membuat profilnya.
Kyle

2

Bahasa pemrograman "tercepat" yang bisa Anda peroleh dengan platform apa pun adalah bahasa rakitan untuk chipset yang Anda hadapi. Pada level itu tidak ada terjemahan. Namun perlu ada beberapa pengetahuan tentang bagaimana chipset mengeksekusi instruksi terutama yang dapat melakukan hal-hal secara paralel.

Konversi dari C ke perakitan sangat "dangkal" sehingga mendekati satu tetapi satu lebih mudah dibaca. Namun ia memiliki banyak lapisan di atasnya karena pustaka standar untuk meningkatkan portabilitas. Tidak ada banyak hal yang perlu dilakukan oleh kompiler untuk mendapatkan kode assembly dan optimisasi yang lebih kuat umumnya ada untuk membuat perubahan spesifik mesin.

C ++ menambahkan bahasa yang lebih kaya. Namun karena bahasa menambahkan begitu banyak kompleksitas, semakin sulit bagi kompiler untuk membuat kode optimal untuk platform.

Lalu kita pergi ke sisi lain dari skala. Bahasa yang ditafsirkan. Ini cenderung paling lambat karena selain melakukan pekerjaan ada beberapa waktu yang dihabiskan untuk mengurai kode dan mengubahnya menjadi panggilan mesin.

Lalu kita memiliki mereka di antaranya. Secara umum mereka memiliki lapisan mesin virtual yang dioptimalkan untuk platform. Dan kompiler akan membuat kode untuk dieksekusi oleh mesin virtual. Terkadang ini terjadi sekaligus seperti perl atau pascal atau ruby ​​atau Python. Atau dalam beberapa tahap seperti java.

Beberapa mesin virtual ini menambahkan gagasan tentang kompiler JIT yang mempercepat runtime juga dengan membuat kode level mesin daripada menerjemahkan kode byte menengah.

Beberapa mesin virtual adalah level rendah yang memungkinkan lebih sedikit terjemahan dari kode byte ke kode mesin. Yang mempercepat sementara menjaga portabilitas.


Secara historis, C dirancang untuk memungkinkan terjemahan yang mudah ke dalam kode mesin. Namun, pada tingkat yang lebih tinggi, mengubah C menjadi kode C yang efisien mensyaratkan bahwa seorang kompiler mencari tahu apa yang coba dilakukan oleh seorang programmer dan kemudian menerjemahkan niat itu menjadi kode mesin. Sebagai contoh, secara historis kode mesin yang setara dengan *p++=*q++;pada banyak mesin lebih cepat daripada array1[i]=array2[i];tetapi pada banyak prosesor, kebalikannya sering benar dan dengan demikian kompiler dapat akhirnya mengubah gaya kode yang sebelumnya menjadi yang terakhir - bukan konversi yang "dangkal".
supercat

Itu biasanya jika Anda melakukannya -O0tidak akan melakukan optimasi. Optimalisasi adalah bonus yang Anda peroleh dengan kompiler, tetapi bahasa itu sendiri dapat menerjemahkan dekat satu ke satu ke perakitan.
Archimedes Trajano

2

Poin yang belum disebutkan adalah bahwa dalam beberapa bahasa, menjalankan kode yang sama berkali-kali akan selalu melakukan urutan tindakan yang sama; komputer hanya perlu menentukan sekali bagian kode apa yang harus dilakukan. Salah satu manfaat utama dari dialek JavaScript "ketat" adalah bahwa setelah mesin JavaScript mengetahui apa yang dilakukan oleh sepotong kode, ia dapat memanfaatkan informasi itu saat dijalankan berikutnya; tanpa "gunakan ketat", itu tidak bisa.

Misalnya, dengan tidak adanya "gunakan ketat", sepotong kode seperti:

function f() { return x; }

dapat mengembalikan variabel X dalam konteks panggilan langsung, jika ada, atau variabel X dari konteks panggilan luar, atau mungkin kembali Undefined. Lebih buruk, dalam satu lingkaran seperti:

for (i=0; i<40; i+=1) { g(i); }

tidak ada cara bagi mesin JavaScript untuk mengetahui apa yang g()mungkin dilakukan dengan i[atau untuk gdirinya sendiri dalam hal ini. Karena gatau idapat secara sah berubah imenjadi string, mesin JavaScript tidak bisa hanya menggunakan penambahan numerik dan perbandingan numerik dalam loop, tetapi harus pada setiap melewati pemeriksaan loop untuk melihat apakah salah satu dari panggilan fungsi telah melakukan sesuatu untuk iatau g. Sebaliknya, dalam dialek "gunakan ketat" [agak waras], mesin JavaScipt dapat memeriksa kode di atas dan mengetahui bahwa setiap melewati loop akan menggunakan variabel numerik yang sama dan menjalankan fungsi yang sama. Dengan demikian hanya perlu mengidentifikasi idan berfungsig sekali, daripada harus mencari mereka di setiap melewati loop - penghematan waktu utama.


2

Ada beberapa jawaban yang cukup profesional di sini, yang ini tidak dekat dengan mereka tetapi mungkin intuitif untuk Anda.

Anda mungkin telah mendengar berkali-kali bahwa ketika Anda perlu melakukan tugas secepat mungkin Anda ingin menulis kode yang mengeksekusinya dalam kumpulan. Itu karena Anda hanya menjalankan perintah yang sebenarnya Anda perlukan untuk menyelesaikan tugas dan tidak lebih. Sementara pada bahasa tingkat tinggi Anda bisa mengimplementasikan tugas ini dalam beberapa baris, kompiler masih perlu menerjemahkannya ke bahasa mesin. Terjemahan ini tidak selalu minimalis karena Anda dapat menulisnya secara langsung. Itu berarti bahwa mesin akan menghabiskan banyak jam untuk menjalankan perintah yang bisa Anda pakai.

Meskipun kompiler sangat canggih saat ini mereka masih tidak efektif karena programmer perakitan terbaik bisa.

Melanjutkan ke arah ini, perintah-perintah yang tidak dibutuhkan tumbuh dalam jumlah mereka (biasanya) karena bahasa diratakan lebih tinggi. (ini tidak 100% benar untuk semua bahasa tingkat tinggi)

Jadi bagi saya, bahasa X lebih cepat daripada bahasa Y (saat runtime) jika untuk bagian kode tertentu, kode mesin X lebih pendek daripada bahasa Y.


Perakitan benar-benar batu. Dibutuhkan seorang seniman sejati untuk mengungguli kompiler terbaik sekalipun.
Johan - mengembalikan Monica

1

Sulit untuk menjawab pertanyaan ini secara definitif karena begitu kompleks dan multidimensi (hampir seperti misalnya membandingkan merek mobil dengan kriteria misc.) Tetapi ada studi ilmiah baru termasuk repositori kode yang sangat baik yang dikenal sebagai kode Rosetta , ( tinjauan wikipedia ). Survei tahun 2014 oleh Nanz dan Furia ini mempelajari pertanyaan ini secara cukup definitif dan ilmiah berdasarkan kriteria tipikal berikut dan analisis kuantitatif yang jarang dari kualitas kode subyektif yang khas. Abstrak berisi beberapa temuan dan generalisasi yang beralasan secara objektif. (Semoga penelitian lain yang membangun hasil ini dapat dilakukan di masa depan.)

  • RQ1. Bahasa pemrograman mana yang menghasilkan kode yang lebih ringkas?

  • RQ2. Bahasa pemrograman mana yang dikompilasi menjadi executable yang lebih kecil?

  • RQ3. Bahasa pemrograman mana yang memiliki kinerja running-time yang lebih baik?

  • RQ4. Bahasa pemrograman mana yang menggunakan memori lebih efisien?

  • RQ5. Bahasa pemrograman mana yang lebih rentan terhadap kegagalan?

Abstrak — Terkadang perdebatan tentang bahasa pemrograman lebih bersifat religius daripada ilmiah. Pertanyaan tentang bahasa mana yang lebih ringkas atau efisien, atau membuat pengembang lebih produktif didiskusikan dengan bersemangat, dan jawaban mereka terlalu sering didasarkan pada anekdot dan keyakinan yang tidak berdasar. Dalam studi ini, kami menggunakan potensi penelitian Rosetta Code yang sebagian besar belum dimanfaatkan, sebuah repositori solusi untuk tugas-tugas pemrograman umum dalam berbagai bahasa, yang menawarkan kumpulan data besar untuk dianalisis. Studi kami didasarkan pada 7.087 solusi program yang sesuai dengan 745 tugas dalam 8 bahasa yang digunakan secara luas mewakili paradigma pemrograman utama (prosedural: C dan Go; berorientasi objek: C # dan Jawa; fungsional: F # dan Haskell; skrip: Python dan Ruby). Analisis statistik kami mengungkapkan, terutama, bahwa: bahasa fungsional dan skrip lebih ringkas daripada bahasa prosedural dan berorientasi objek; C sulit dikalahkan dalam hal kecepatan mentah pada input besar, tetapi perbedaan kinerja atas input berukuran sedang kurang jelas dan memungkinkan bahkan bahasa yang ditafsirkan menjadi kompetitif; dikompilasi dengan bahasa yang diketik dengan kuat, di mana lebih banyak cacat dapat ditangkap pada waktu kompilasi, kurang rentan terhadap kegagalan runtime daripada bahasa yang ditafsirkan atau diketik dengan lemah. Kami membahas implikasi hasil ini untuk pengembang, perancang bahasa, dan pendidik. di mana lebih banyak cacat dapat ditangkap pada waktu kompilasi, kurang rentan terhadap kegagalan runtime daripada bahasa yang ditafsirkan atau diketik dengan lemah. Kami membahas implikasi hasil ini untuk pengembang, perancang bahasa, dan pendidik. di mana lebih banyak cacat dapat ditangkap pada waktu kompilasi, kurang rentan terhadap kegagalan runtime daripada bahasa yang ditafsirkan atau diketik dengan lemah. Kami membahas implikasi hasil ini untuk pengembang, perancang bahasa, dan pendidik.


0

Bahasa komputer hanyalah abstraksi dari perintah untuk menjelaskan pada komputer apa yang harus dilakukan.

Anda bahkan dapat menulis dalam bahasa komputer Pythondan mengompilasinya dengan kompiler C (cython).

Ingatlah ini, kecepatan bahasa komputer tidak dapat dibandingkan.

Tetapi Anda dapat membandingkan kompiler untuk bahasa yang sama hingga beberapa ekstensi. Misalnya GNU Ckompiler versus Intel Ckompiler. (Cari patokan kompiler)


2
Jika Anda ingin membuat komentar tentang pertanyaan, silakan gunakan kotak komentar, bukan jawaban Anda. Perhatikan bahwa ini adalah Computer Science Stack Exchange dan ilmu komputer bukan pemrograman, sama seperti literatur tidak memproses kata. Pertanyaan pemrograman langsung pada Rekayasa Perangkat Lunak atau Stack Overflow .
David Richerby
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.