Mengapa CIL dan CLR diperlukan dalam .NET?

Saya melihat gambar yang bagus di sini . Saya belajar bahwa semua kompiler yang mendukung bahasa .net mengkonversi kode sumber ke CILformat. Sekarang Microsoft tidak pernah mendatangkan .NETsemua sistem operasi dengan menulis CLR untuk semua sistem operasi. Lalu mengapa menyimpan format kode antara dan CLR untuk menjalankan CIL itu. Apakah itu bukan sakit kepala yang harus dihadapi? Mengapa Microsoft memilih menjadi seperti ini?

EDIT Arsitektur ini harganya mahal. Itu akan mengurangi kinerja, bukan? Java melakukan ini untuk menjaga independensi platform, untuk alasan apa. NET melakukannya? Mengapa tidak menyimpan kompiler seperti C biasa. Cara apa pun juga akan memerlukan kompiler untuk mengkonversi kode ke CIL jika saya perlu menambahkan bahasa baru, satu-satunya perbedaan yang akan dibuat adalah bahasa target. Ini semua.

.net

— vikkyhacks
sumber

Karena lebih mudah menulis compiler ke CIL. Dan lebih mudah untuk menulis satu CIL ke kompiler asli daripada kompiler untuk masing-masing dan setiap bahasa ke bahasa asli.

— Oded

@ scratchetfreak: itu mungkin menjadi alasan bagi MS untuk tidak mem-porting CLR ke platform lain, tetapi itu bukan alasan untuk memiliki CLR di tempat pertama (yang sebenarnya membuat port lebih mudah , sehingga argumen Anda terdengar seperti MS bashing, maaf)

— Doc Brown

Juga downvote untuk 'M $', apa ini, 1998?

— Alan B

Eric Lippert membahas hal ini (mulai dari paragraf 3; 2 paragraf pertama adalah tentang Roslyn). Jawaban singkatnya adalah bahwa komentar Oded dan jawaban Telastyn benar; Anda hanya perlu mengkode kompiler <Jumlah sistem operasi> + <Jumlah bahasa> alih-alih kompiler <Jumlah sistem operasi> * <Jumlah bahasa>.

— Brian

@busy_wait: Halaman yang direferensikan menyebutkan beberapa kerugian. Sebagai contoh, "informasi konfigurasi dalam dua aplikasi mungkin menghasilkan keputusan mengikat yang berbeda untuk perakitan dependen yang sama." Menghasilkan dengan cepat menghindari masalah ini. Ini menyiratkan bahwa kompilasi benar-benar perlu dilakukan setelah aplikasi didistribusikan (dan pada kenyataannya, NGEN harus dijalankan pada setiap mesin target; itu tidak dapat dijalankan oleh distributor).

— Brian

Jawaban:

Karena mereka hanya perlu menulis satu kompiler untuk C # ke CIL - yang merupakan bagian yang sulit. Membuat penerjemah (atau lebih sering, kompiler Just-In-Time) untuk CIL per platform relatif mudah dibandingkan dengan menulis kompiler dari kode eksekusi C # ke (per platform).

Selain itu, runtime dapat menangani apa pun yang dikompilasi ke CIL. Jika Anda menginginkan bahasa baru (seperti F #), Anda hanya perlu menulis satu kompiler untuk itu dan Anda secara ajaib mendapatkan semua dukungan platform untuk hal-hal yang didukung .NET.

Oh, dan saya bisa mengambil .NET dll dan menjalankannya di windows atau di linux via Mono tanpa kompilasi ulang (dengan asumsi semua dependensi saya puas).

Adapun kinerja, itu masih bisa diperdebatkan. Ada "pre-compiler" yang pada dasarnya mengambil CIL dan membuat binari asli. Yang lain berpendapat bahwa kompiler just-in-time dapat membuat optimasi bahwa kompiler statis tidak bisa. Dalam pengalaman saya, itu sangat tergantung pada apa aplikasi Anda lakukan dan pada platform apa Anda menjalankannya (kebanyakan seberapa bagus JITer pada platform itu). Sangat jarang bagi saya untuk mengalami skenario di mana .NET tidak cukup baik .

— Telastyn
sumber

"penerjemah" `? Saya pikir selalu MS hanya menyediakan JITter?

— Doc Brown

@DocBrown - eh, ya - salah kaprah pada bagian saya. Pemasangan.

— Telastyn

+1, dapatkah Anda menambahkan sedikit penjelasan untuk hasil edit saya sehingga saya dapat menerima jawaban ini

— vikkyhacks

Runtime berkinerja tinggi sering menggabungkan interpreter dan kompiler JIT (eksekusi mode campuran). Saya tidak yakin tentang .NET, tetapi banyak VM Java menggunakan pendekatan ini.

— Cyanfish

@busy_wait: Segala macam hal. Metode inlining, menyalin propagasi, menghapus kode yang tidak perlu, mengubah perkalian / pembagian menjadi shift, operasi aritmatika lainnya menggunakan readonlybidang. Kompiler tradisional dapat melakukan beberapa optimasi ini tetapi hanya ketika mereka dapat dideteksi oleh analisis statis. Sebaliknya, jitter dapat mengetahui saat runtime bahwa (misalnya) bagian kode tidak melakukan pekerjaan yang bermanfaat karena objek atau variabel yang dimodifikasi tidak dirujuk di tempat lain. Saya bukan ahli kegugupan tetapi pada dasarnya pertanyaan tentang kekuatan analisis dinamis vs statis.

— Aaronaught

.NET memiliki bahasa perantara (CIL / MSIL) dan implementasi spesifik platform dari runtime platform-independent (CLR) karena alasan yang sama dengan Java. Microsoft bermaksud C # untuk bersaing secara langsung dengan Java, dan memang demikian, pada OS yang Microsoft targetkan (miliknya sendiri).

Keuntungannya, meskipun .NET hanya didukung pada platform Windows (atau OS lain yang memiliki .NET seperti Mono / Linux), mirip dengan Java:

Managed Memory Runtime - Tidak seperti C / C ++ yang tidak dikelola, pengembang C # / VB.NET tidak perlu khawatir tentang pengontrolan umur objek secara ketat. Seperti Java, CLR memiliki pengumpul sampah yang secara otomatis membebaskan objek di heap yang meninggalkan ruang lingkup. Sementara ini mungkin tampak kecil bagi seseorang yang digunakan untuk runtime yang tidak dikelola, ini memiliki keuntungan sekunder ekstrem untuk mencegah "sihir hitam" aritmatika pointer yang sangat umum di C / C ++.
Platform Independence - Windows Vista dan Windows 7 bekerja secara berbeda dari Windows XP. Windows 8 bekerja masih berbeda. Versi Windows Mobile termasuk Windows 8 Mobile berfungsi berbeda lagi. Perangkat keras berbeda, arsitektur berbeda, kemampuan berbeda. Sementara lingkungan target masih penting bagi pengembang .NET, jumlah pengetahuan khusus jauh berkurang dibandingkan dengan apa yang harus diketahui untuk membangun program C / C ++ yang kompatibel untuk semua OS ini. AC # dev mendapat lebih banyak gratis.
Dukungan aplikasi web - Saya belum melihat aplikasi web yang berhadapan dengan klien yang ditulis oleh server dari bawah ke atas di C ++. Server web , tentu saja, Apache, ISS, semuanya biasanya berjalan melawan runtime yang tidak dikelola karena alasan kecepatan / efisiensi. Namun, C ++ bukan bahasa yang digunakan untuk membangun aplikasi web. C # adalah (seperti halnya Java). Itu dirancang dari bawah ke atas untuk mendukung generasi berikutnya dari paradigma ASP Microsoft. Ini adalah kode yang dirancang untuk dijalankan di kotak pasir; yang sandbox (plugin ASP.NET ke ISS atau "desktop" CLR) relatif tidak penting.
Kemandirian bahasa / runtime - Kompiler C ++ mengambil kode sumber C ++ dan menghasilkan kode perakitan untuk satu arsitektur prosesor menggunakan satu bahasa mesin. Untuk mendukung arsitektur dan / atau bahasa mesin yang berbeda, kompiler yang sepenuhnya baru harus ditulis (dan pustaka runtime yang sepenuhnya baru harus dikompilasi). Kompiler AC # mengambil kode sumber C # dan menghasilkan CIL, yang diterjemahkan oleh JITer khusus perangkat keras ke kode mesin. JITer yang sama dapat menerjemahkan program CIL apa pun sumbernya (dan ada beberapa; C #, VB.NET, F #, dan sejumlah port bahasa "Besi" seperti IronHaskell, IronRuby, IronLisp, dll). Kompiler yang sama dapat mengubah satu bahasa menjadi CIL yang dapat dijalankan oleh JITer, apa pun perangkat kerasnya.
Fokus pada kode "benar" - Untuk pengembang C ++, ada banyak cara "benar" untuk melakukan sesuatu, tergantung pada apa yang paling penting; efisiensi memori, efisiensi CPU, kemandirian perangkat keras, kemandirian OS, dll. Kode dapat terlihat sangat berbeda ketika masing-masing adalah prioritas. C # dirancang oleh sebuah kelompok yang mengingat pelajaran konseptual dari Fowler dan rekan-rekannya (yang bekerja untuk mereformasi desain kode dalam komunitas C ++ dengan mengajarkan prinsip-prinsip berorientasi objek kepada komunitas yang sebagian besar bergerak ke dalamnya dari C), karena juga pelajaran praktis yang dipelajari oleh bahasa-bahasa yang datang sebelumnya (termasuk Jawa, dan kepatuhannya yang hampir fanatik terhadap Objek yang Mahakuasa, ketika penunjuk fungsi gaya C ++ lama yang baik akan melakukan pekerjaan dengan jauh lebih bersih dan tidak menjadi objek yang kurang - berorientasi).

Untuk alasan antitrust, MS berhati-hati untuk tidak terlihat "mengganggu" terlalu banyak di platform utama lainnya seperti Android, Mac OSX / iOS dan Linux; namun, memang ada tim yang mengembangkan untuk ketiga platform ini. Ada versi MS-dikembangkan Office untuk OSX, ada banyak aplikasi termasuk aplikasi Office interop untuk iOS dan Android, Skype (sekarang produk Microsoft) berjalan di Linux, dan Microsoft bahkan telah terlihat berkontribusi pada kernel Linux (terutama di pola pikir virtualisasi).

— KeithS
sumber

"Saya belum melihat aplikasi web yang berhadapan dengan klien dan server-scripted ditulis dari bawah ke atas di C ++." - Di mana Anda menempatkan CGI di masa lalu? Aplikasi web pertama saya (sepele seperti itu) adalah 100% C. Saat itu (pertengahan 90-an) lebih mudah untuk menulis .c dan .h untuk melakukan pekerjaan standar dalam cgi (bahasa 'scripting' hanya muncul di tempat kejadian juga).

hm ... CGI, CGI ... Saya pikir saya pernah mendengarnya, tapi saya dengan KeithS, saya belum benar-benar melihatnya :)

— DXM

@DXM model lama konten dinamis adalah untuk proses server web garpu proses dan meletakkan segala sesuatu di tempat standar (params permintaan dan sejenisnya masuk dalam variabel lingkungan tertentu) - Common Gateway Interface. Output dari proses itu kemudian dikirim kembali sebagai konten. Di masa lalu, lebih mudah untuk menemukan seorang programmer yang tahu C atau C ++ daripada perl atau python (dan sh sangat kikuk untuk pekerjaan seperti itu).

Jangan meremehkan pentingnya kesamaan dengan Java. Sun baru saja menggugat MS untuk port JVM mereka dan memenangkan beberapa poin hukum (bodoh, IMHO). CIL dan CLR terinspirasi oleh hal itu, dan Anda akan melihat bahwa J # sedekat mungkin dengan Java tanpa memicu tindakan hukum lebih lanjut. Perbedaan besar adalah bahwa CLR adalah agnostik bahasa. Anda benar-benar dapat menulis sebuah program dalam campuran C #, F #, dan J # jika itu yang dibutuhkan. Cobalah untuk mencampur Java dengan perpustakaan dalam bahasa lain dan dapatkan program yang stabil.

— RBerteig

Tetapi interop antara MSIL dan kode asli keduanya didefinisikan dengan baik dan hanya berfungsi. Dan ternyata diharapkan hanya bekerja dengan desain, dan oleh sikap komunitas pengguna.

— RBerteig

OS Windows tersedia untuk berbagai jenis CPU, saat ini kebanyakan x64, x86, Intel, ARM.

CIL / CLR independen dari platform perangkat keras - perbedaan-perbedaan ini "diabstraksikan" oleh lingkungan eksekusi IL. Sebagai contoh, perakitan .NET dikompilasi untuk "CPU apa saja" biasanya dapat dieksekusi pada Win64 sebagai proses 64 bit, dan Win32 sebagai proses 32 bit, tanpa perlu menyediakan berbagai executable.

Terlebih lagi, CIL memungkinkan metadata untuk disimpan dalam rakitan yang tidak mudah dilakukan dengan DLL asli (dimungkinkan, tentu saja, MS melakukan ini sebelumnya dengan komponen COM, tetapi teknologi itu tidak pernah semudah menangani komponen .NET). Itu membuat pembuatan komponen perangkat lunak jauh lebih sederhana dan merupakan dasar refleksi / introspeksi dalam semua bahasa .NET.

— Doc Brown
sumber

Hanya untuk menambahkan sedikit ke ini, mereka tidak hanya memungkinkan berbagai jenis CPU tetapi bahkan versi yang berbeda (Core i3 / i5 / i7) dan vendor (Intel vs AMD) dalam jenis CPU yang sama (misalnya semua x64) mungkin memiliki perbedaan set instruksi perakitan yang dapat dimanfaatkan oleh kompiler JIT

— DXM

@DXM: dan Anda tahu JIT sebenarnya tidak? Atau ini lebih bersifat hipotesis?

— Doc Brown

Setidaknya sebuah blog MSDN mengklaim bahwa kompiler JIT melakukan itu (atau memang, 8 tahun yang lalu).

@DocBrown: Jelas saya tidak memiliki bahan referensi di tangan, tapi saya pikir saya ingat pernah membaca sesuatu tentang ini sejak lama. Terima kasih delnan, untuk menemukan tautannya. Itu masuk akal karena kita tahu produsen chip ingin menambahkan instruksi mereka sendiri di atas standar x86-x64 jadi jika mesin dapat mengambil keuntungan mengapa tidak?

— DXM