Apa hubungan antara penerjemah meta-sirkuler, mesin virtual, dan peningkatan kinerja?

12

Saya telah membaca tentang interpreter meta-sirkuler di web (termasuk SICP) dan saya telah melihat ke dalam kode beberapa implementasi (seperti PyPy dan Narcissus).

Saya sudah membaca sedikit tentang dua bahasa yang memanfaatkan evaluasi metacircular, Lisp dan Smalltalk. Sejauh yang saya mengerti Lisp adalah kompiler self-hosting pertama dan Smalltalk memiliki implementasi JIT "benar" pertama.

Satu hal yang belum sepenuhnya saya pahami adalah bagaimana para penerjemah / penyusun itu dapat mencapai kinerja yang begitu baik atau, dengan kata lain, mengapa PyPy lebih cepat daripada CPython? Apakah karena refleksi?

Dan juga, penelitian Smalltalk saya membuat saya percaya bahwa ada hubungan antara JIT, mesin virtual dan refleksi. Mesin Virtual seperti JVM dan CLR memungkinkan banyak jenis introspeksi dan saya percaya mereka memanfaatkannya dalam kompilasi Just-in-Time (dan AOT, saya kira?). Tapi sejauh yang saya tahu, Mesin Virtual seperti CPU, karena mereka memiliki set instruksi dasar. Apakah Mesin Virtual efisien karena mereka memasukkan informasi jenis dan referensi, yang akan memungkinkan refleksi agnostik bahasa?

Saya menanyakan hal ini karena banyak bahasa yang ditafsirkan dan dikompilasi sekarang menggunakan bytecode sebagai target (LLVM, Parrot, YARV, CPython) dan VM tradisional seperti JVM dan CLR telah memperoleh peningkatan kinerja yang luar biasa. Saya telah diberitahu bahwa ini tentang JIT, tetapi sejauh yang saya tahu JIT bukanlah hal yang baru sejak Smalltalk dan Sun sendiri telah melakukannya sebelum Jawa. Saya tidak ingat VMs berkinerja sangat baik di masa lalu, tidak banyak yang non-akademik di luar JVM dan .NET dan kinerja mereka jelas tidak sebagus sekarang (saya berharap saya bisa mendapatkan klaim ini tapi saya berbicara dari pengalaman pribadi).

Lalu tiba-tiba, di akhir tahun 2000-an sesuatu berubah dan banyak VM mulai muncul bahkan untuk bahasa yang sudah mapan, dan dengan kinerja yang sangat baik. Apakah ada sesuatu yang ditemukan tentang implementasi JIT yang memungkinkan hampir setiap VM modern meroket dalam kinerja? Mungkin kertas atau buku?

virtual-machine reflection jit smalltalk Gomi
sumber
3
Uang. Uang yang dulu dituangkan ke dalam C ++ dan Fortran sekarang dituangkan ke dalam HotSpot, CLR, Mono, V8, Nitro, SpiderMonkey, dll.
Jörg W Mittag
Saya hanya bisa menebak, tapi saya pikir ini hanya peningkatan dari waktu ke waktu, seperti dijelaskan di sini joelonsoftware.com/articles/fog000000001717.html
Doc Brown
1
RE bagaimana PyPy bisa lebih cepat daripada CPython: Itu tidak ditulis dalam Python, itu ditulis dalam bahasa yang sangat berbeda yang dapat dioptimalkan secara efektif AOT .
1
@Gomi Ini bukan tentang seberapa mirip bahasa implementasi dengan bahasa yang diterapkan. Ada penerjemah JavaScript, Lisp, Prolog, SmallTalk, dan Ruby yang ditulis dalam RPython dan mereka mendapatkan barang yang sama persis dengan yang ditawarkan PyPy. Satu-satunya alasan RPython didasarkan pada Python adalah karena ia dibuat oleh sekelompok penggemar Python. Fitur-fitur RPython yang membuat PyPy cepat tidak ada hubungannya dengan Python: Pembuatan kompiler JIT otomatis, pengumpul sampah, dll. - dan ya, sebagian besar dari itu pada prinsipnya dapat dilakukan dengan menggunakan bahasa lain. Anda harus membuat kompiler baru.
4
-1 karena Anda tampaknya memiliki setidaknya 3 pertanyaan berbeda di sini: (a) Mengapa implementasi meta-bundar begitu baik? (B) Apakah VM efisien karena jenis informasi, dan apakah introspeksi bermanfaat untuk kinerja? (c) Bagaimana popularitas VM melonjak di akhir tahun 2000-an, dan mengapa mereka tiba-tiba memiliki kinerja yang baik? Saya pikir lebih baik bertanya secara terpisah.
Oak

Jawaban:

1

2 dari 3: Tidak ada hubungan antara runtime bahasa "meta-circular" dan "high-performance". Meta-circular runtimes yang mencapai kinerja tinggi melakukannya dengan mengkompilasi JIT ke kode asli, dan menjalankan kode asli. Tidak ada alasan mengapa hi-perf Python runtime Anda harus ditulis dalam Python, atau Lisp di Lisp, dll. Tetapi jika Anda berpikir bahwa bahasa Anda lebih kuat, ekspresif, dll. Daripada yang lain, mengapa tidak menggunakannya untuk menulis runtime sendiri? Atau jika Anda tidak berpikir bahwa bahasa Anda entah bagaimana "lebih baik" daripada yang lain, mengapa Anda kesulitan menerapkannya sama sekali?

Alex D
sumber