Apa fitur semantik dari Python (dan bahasa dinamis lainnya) yang berkontribusi terhadap kelambatannya?
Tidak ada
Kinerja implementasi bahasa adalah fungsi dari uang, sumber daya, dan tesis PhD, bukan fitur bahasa. Self jauh lebih dinamis daripada Smalltalk dan sedikit lebih dinamis daripada Python, Ruby, ECMAScript, atau Lua, dan memiliki VM yang mengungguli semua Lisp dan Smalltalk VM yang ada (pada kenyataannya, distribusi Self dikirimkan bersama dengan interpreter Smalltalk kecil yang ditulis dalam Self , dan bahkan itu lebih cepat dari kebanyakan VM Smalltalk yang ada), dan bersaing dengan, dan terkadang bahkan lebih cepat daripada implementasi C ++ saat itu.
Kemudian, Sun menghentikan pendanaan Self, dan IBM, Microsoft, Intel, and Co. mulai mendanai C ++, dan tren berbalik. Pengembang mandiri meninggalkan Sun untuk memulai perusahaan mereka sendiri, di mana mereka menggunakan teknologi yang dikembangkan untuk VM Self untuk membangun salah satu VM Smalltalk tercepat (VM Animorphic), dan kemudian Sun membeli kembali perusahaan itu, dan versi yang sedikit dimodifikasi dari bahwa Smalltalk VM sekarang lebih dikenal dengan nama "HotSpot JVM". Ironisnya, programmer Java memandang rendah pada bahasa dinamis karena "lambat", padahal sebenarnya, Javalambat sampai mengadopsi teknologi bahasa dinamis. (Ya, itu benar: HotSpot JVM pada dasarnya adalah Smalltalk VM. Verifier bytecode melakukan banyak pengecekan tipe, tetapi begitu bytecode diterima oleh verifier, VM, dan terutama optimizer dan JIT tidak benar-benar melakukan banyak yang tertarik dengan tipe statis!)
CPython sama sekali tidak melakukan banyak hal yang membuat bahasa dinamis (atau lebih tepatnya pengiriman dinamis) cepat: kompilasi dinamis (JIT), optimisasi dinamis, inferensi spekulatif, optimasi adaptif, de-optimasi dinamis, umpan balik / inferensi tipe dinamis. Ada juga masalah yang hampir seluruh inti dan pustaka standar ditulis dalam C, yang berarti bahwa bahkan jika Anda membuat Python 100x lebih cepat tiba-tiba, itu tidak akan banyak membantu Anda, karena sekitar 95% dari kode dieksekusi oleh Program python adalah C, bukan Python. Jika semuanya ditulis dalam Python, bahkan speedup moderat akan membuat efek longsoran salju, di mana algoritma menjadi lebih cepat, dan struktur data inti menjadi lebih cepat, tetapi tentu saja struktur data inti juga digunakan dalam algoritma, dan algoritma inti dan data inti struktur digunakan di tempat lain,
Ada beberapa hal yang terkenal buruk untuk bahasa OO yang dikelola memori (dinamis atau tidak) dalam sistem saat ini. Memori Virtual dan Perlindungan Memori dapat menjadi pembunuh untuk kinerja pengumpulan sampah pada khususnya, dan kinerja sistem pada umumnya. Dan itu benar-benar tidak perlu dalam bahasa yang aman-memori: mengapa melindungi terhadap akses memori ilegal ketika tidak ada memori yang mengakses dalam bahasa untuk memulai? Azul telah menemukan untuk menggunakan MMU modern yang kuat (Intel Nehalem dan yang lebih baru, dan AMD yang setara) untuk membantu pengumpulan sampah alih-alih menghalanginya, tetapi meskipun didukung oleh CPU, subsistem memori saat ini dari OS mainstream tidak cukup kuat untuk memungkinkan ini (itulah sebabnya Azul's JVM sebenarnya berjalan tervirtualisasi pada bare metal di samping OS, bukan di dalamnya).
Dalam proyek Singularity OS, Microsoft telah mengukur dampak ~ 30% pada kinerja sistem ketika menggunakan perlindungan MMU alih-alih sistem tipe untuk pemisahan proses.
Hal lain yang diperhatikan Azul ketika membangun CPU Java khusus mereka adalah bahwa CPU arus utama modern fokus pada hal yang sepenuhnya salah ketika mencoba untuk mengurangi biaya cache yang hilang: mereka mencoba untuk mengurangi jumlah cache yang hilang melalui hal-hal seperti prediksi cabang, pengambilan memori, dan seterusnya. Tetapi, dalam program OO yang sangat polimorfik, pola akses pada dasarnya pseudo-acak, tidak ada yang bisa diprediksi. Jadi, semua transistor itu hanya terbuang sia-sia, dan yang harus dilakukan adalah mengurangi biaya setiap cache yang hilang. (Total biaya adalah #misses * biaya, arus utama mencoba membawa yang pertama turun, Azul yang kedua.) Akselerator Java Compute Azul dapat memiliki 20.000 cache cache yang hilang secara bersamaan dalam penerbangan dan masih membuat kemajuan.
Ketika Azul memulai, mereka pikir mereka akan mengambil beberapa komponen I / O yang tidak tersedia dan mendesain inti CPU khusus mereka sendiri, tetapi apa yang sebenarnya perlu mereka lakukan adalah kebalikannya: mereka mengambil standar yang agak standar. rak 3-address inti RISC dan merancang pengontrol memori, MMU, dan subsistem cache mereka sendiri.
tl; dr : "Kelambatan" Python bukan properti bahasa tetapi a) implementasi naif (primer), dan b) fakta bahwa CPU dan OS modern dirancang khusus untuk membuat C berjalan cepat, dan fitur-fiturnya miliki untuk C tidak membantu (cache) atau bahkan secara aktif menyakiti (virtual memory) kinerja Python.
Dan Anda dapat memasukkan hampir semua bahasa yang dikelola memori dengan polimorfisme ad-hoc yang dinamis di sini ... ketika datang ke tantangan implementasi yang efisien, bahkan Python dan Java cukup banyak "bahasa yang sama".