Apa yang menghalangi Ruby, Python untuk mendapatkan kecepatan Javascript V8? [Tutup]

Apakah ada fitur Ruby / Python yang menghalangi implementasi optimasi (mis. Inline caching ) yang dimiliki mesin V8?

Python dikembangkan bersama oleh orang-orang Google sehingga tidak boleh diblokir oleh paten perangkat lunak.

Atau ini lebih merupakan masalah sumber daya yang dimasukkan ke dalam proyek V8 oleh Google.

Apa yang menghalangi Ruby, Python untuk mendapatkan kecepatan Javascript V8?

Tidak ada.

Baiklah, oke: uang. (Dan waktu, orang, sumber daya, tetapi jika Anda memiliki uang, Anda dapat membelinya.)

V8 memiliki tim insinyur yang brilian, sangat terspesialisasi, sangat berpengalaman (dan dengan demikian dibayar sangat tinggi) mengerjakannya, yang memiliki pengalaman puluhan tahun (saya berbicara secara individu - secara kolektif lebih seperti berabad-abad) dalam menciptakan eksekusi kinerja tinggi mesin untuk bahasa OO dinamis. Mereka pada dasarnya adalah orang yang sama yang juga menciptakan Sun HotSpot JVM (di antara banyak lainnya).

Lars Bak, pengembang utama, telah benar-benar bekerja pada VM selama 25 tahun (dan semua VM tersebut mengarah ke V8), yang pada dasarnya adalah seluruh hidupnya (profesional). Beberapa orang yang menulis Ruby VM bahkan belum berusia 25 tahun.

Apakah ada fitur Ruby / Python yang menghalangi implementasi optimasi (mis. Inline caching) yang dimiliki mesin V8?

Mengingat setidaknya IronRuby, JRuby, MagLev, MacRuby dan Rubinius memiliki monomorfik (IronRuby) atau caching inline polimorfik, jawabannya jelas tidak.

Implementasi Ruby modern sudah melakukan banyak optimasi. Misalnya, untuk operasi tertentu, Hashkelas Rubinius lebih cepat daripada kelas YARV. Sekarang, ini tidak terdengar sangat menarik sampai Anda menyadari bahwa Hashkelas Rubinius diimplementasikan dalam 100% Ruby murni, sementara YARV diimplementasikan dalam 100% tangan-dioptimalkan C.

Jadi, setidaknya dalam beberapa kasus, Rubinius dapat menghasilkan kode yang lebih baik daripada GCC!

Atau ini lebih merupakan masalah sumber daya yang dimasukkan ke dalam proyek V8 oleh Google.

Iya. Bukan hanya Google. Silsilah kode sumber V8 berusia 25 tahun sekarang. Orang-orang yang bekerja pada V8 juga menciptakan Self VM (hingga hari ini salah satu mesin eksekusi bahasa OO dinamis tercepat yang pernah dibuat), Animorphic Smalltalk VM (hingga hari ini salah satu mesin eksekusi Smalltalk tercepat yang pernah dibuat), HotSpot JVM (JVM tercepat yang pernah dibuat, mungkin periode VM tercepat) dan OOVM (salah satu VM Smalltalk paling efisien yang pernah dibuat).

Faktanya, Lars Bak, pengembang utama V8, mengerjakan semua hal itu, ditambah beberapa lainnya.

Ada lebih banyak dorongan untuk mengoptimalkan penerjemah JavaScript, oleh karena itu kami melihat begitu banyak sumber daya dimasukkan di antara Mozilla, Google, dan Microsoft. JavaScript harus diunduh, diuraikan, dikompilasi, dan dijalankan dalam waktu nyata sementara manusia (yang biasanya tidak sabar) sedang menunggunya, itu harus dijalankan SAAT seseorang berinteraksi dengan itu, dan melakukan ini di klien-end yang tidak terkendali lingkungan yang bisa berupa komputer, telepon, atau pemanggang roti. Ini HARUS efisien untuk berjalan di bawah kondisi ini secara efektif.

Python dan Ruby dijalankan di lingkungan yang dikontrol oleh pengembang / penyebar. Server gemuk atau sistem desktop umumnya di mana faktor pembatasnya adalah hal-hal seperti memori atau disk I / O dan bukan waktu eksekusi. Atau di mana optimisasi non-mesin seperti caching dapat dimanfaatkan. Untuk bahasa-bahasa ini, mungkin lebih masuk akal untuk fokus pada fitur bahasa dan pustaka yang ditetapkan pada pengoptimalan kecepatan.

Manfaat sampingan dari ini adalah bahwa kami memiliki dua mesin JavaScript open source berkinerja tinggi yang dapat dan sedang dirancang ulang untuk semua jenis aplikasi seperti Node.js.

Bagian yang baik dari itu berkaitan dengan komunitas. Python dan Ruby sebagian besar tidak memiliki dukungan perusahaan. Tidak ada yang dibayar untuk bekerja di Python dan Ruby penuh waktu (dan mereka terutama tidak dibayar untuk bekerja di CPython atau MRI sepanjang waktu). V8, di sisi lain, didukung oleh perusahaan IT paling kuat di dunia.

Selain itu, V8 bisa lebih cepat karena satu-satunya hal yang penting bagi orang-orang V8 adalah penerjemah - mereka tidak memiliki perpustakaan standar untuk dikerjakan, tidak ada masalah tentang desain bahasa. Mereka hanya menulis penerjemah. Itu dia.

Ini tidak ada hubungannya dengan hukum kekayaan intelektual. Python juga tidak dikembangkan bersama oleh orang-orang Google (pembuatnya bekerja di sana bersama beberapa komuter lain, tetapi mereka tidak dibayar untuk mengerjakan Python).

Kendala lain untuk kecepatan Python adalah Python 3. Adopsinya tampaknya menjadi perhatian utama pengembang bahasa - sampai-sampai mereka telah membekukan pengembangan fitur bahasa baru sampai implementasi lain menyusul.

Ke detail teknis, saya tidak tahu banyak tentang Ruby, tetapi Python memiliki sejumlah tempat di mana optimisasi dapat digunakan (dan Unladen Swallow, proyek Google, mulai mengimplementasikannya sebelum menggigit debu). Berikut adalah beberapa optimasi yang mereka rencanakan . Saya bisa melihat Python mendapatkan kecepatan V8 di masa depan jika JIT a la PyPy diimplementasikan untuk CPython, tetapi sepertinya tidak mungkin untuk tahun-tahun mendatang (fokus saat ini adalah adopsi Python 3, bukan JIT).

Banyak juga yang merasa bahwa Ruby dan Python dapat mengambil manfaat yang sangat besar dengan menghapus kunci juru bahasa global masing-masing .

Anda juga harus memahami bahwa Python dan Ruby keduanya bahasa yang jauh lebih berat daripada JS - mereka menyediakan jauh lebih banyak cara perpustakaan standar, fitur bahasa, dan struktur. Sistem kelas orientasi objek saja menambah banyak bobot (dalam cara yang baik, saya pikir). Saya hampir menganggap Javascript sebagai bahasa yang dirancang untuk disematkan, seperti Lua (dan dalam banyak hal, mereka mirip). Ruby dan Python memiliki serangkaian fitur yang lebih kaya, dan ekspresifitas itu biasanya akan datang dengan mengorbankan kecepatan.

Kinerja tampaknya tidak menjadi fokus utama pengembang Python inti, yang tampaknya merasa bahwa "cukup cepat" cukup baik, dan bahwa fitur yang membantu pemrogram menjadi lebih produktif lebih penting daripada fitur yang membantu komputer menjalankan kode lebih cepat.

Memang, bagaimanapun, ada proyek Google (sekarang ditinggalkan), unladen-walet , untuk menghasilkan juru bahasa Python lebih cepat yang kompatibel dengan juru bahasa standar. PyPy adalah proyek lain yang bermaksud menghasilkan Python yang lebih cepat. Ada juga Psyco , cikal bakal PyPy, yang dapat memberikan peningkatan kinerja ke banyak skrip Python tanpa mengubah seluruh penerjemah, dan Cython , yang memungkinkan Anda menulis perpustakaan C berkinerja tinggi untuk Python menggunakan sesuatu yang sangat mirip dengan sintaksis Python.

Pertanyaan yang menyesatkan. V8 adalah implementasi JIT (compiler just in time) dari JavaScript dan dalam implementasi non-browser Node.js yang paling populer itu dibangun di sekitar sebuah loop acara. CPython bukan JIT & tidak terjadi. Tapi ini ada di Python paling umum di proyek PyPy - sebuah CPYthon 2.7 (dan segera menjadi 3.0+) JIT yang kompatibel. Dan ada banyak perpustakaan server yang terjadi seperti Tornado misalnya. Tes dunia nyata ada antara PyPy menjalankan Tornado vs Node.js dan perbedaan kinerja sedikit.

Saya baru saja membahas pertanyaan ini dan ada juga alasan teknis besar untuk perbedaan kinerja yang tidak disebutkan. Python memiliki ekosistem ekstensi perangkat lunak yang sangat besar, tetapi sebagian besar ekstensi ini ditulis dalam bahasa C atau bahasa tingkat rendah lainnya untuk kinerja dan sangat terikat dengan API CPython.

Ada banyak teknik terkenal (JIT, pengumpul sampah modern, dll) yang dapat digunakan untuk mempercepat implementasi CPython tetapi semua akan membutuhkan perubahan besar pada API, memecah sebagian besar ekstensi dalam proses. CPython akan lebih cepat, tetapi banyak hal yang membuat Python begitu menarik (tumpukan perangkat lunak yang luas) akan hilang. Contohnya, ada beberapa implementasi Python lebih cepat di luar sana tetapi mereka memiliki sedikit daya tarik dibandingkan dengan CPython.

Karena prioritas desain yang berbeda dan tujuan penggunaan kasus saya percaya.

Secara umum tujuan utama scripting (alias dinamis) bahasa adalah untuk menjadi "perekat" antara panggilan fungsi asli. Dan fungsi asli ini harus a) mencakup area yang paling kritis / sering digunakan dan b) seefektif mungkin.

Berikut adalah contoh: jQuery semacam menyebabkan iOS Safari untuk membekukan Pembekuan ada disebabkan oleh penggunaan berlebihan dari panggilan get-by-pemilih. Jika get-by-selector akan diimplementasikan dalam kode asli dan efektif itu tidak akan menjadi masalah sama sekali.

Pertimbangkan demo ray-tracer yang sering digunakan demo untuk demonstrasi V8. Dalam dunia Python dapat diimplementasikan dalam kode asli karena Python menyediakan semua fasilitas untuk ekstensi asli. Tetapi dalam ranah V8 (kotak sisi klien) Anda tidak memiliki pilihan lain selain membuat VM menjadi [sub] seefektif mungkin. Maka satu-satunya opsi lihat implementasi ray-tracer di sana adalah dengan menggunakan kode skrip.

Jadi beda prioritas dan motivasi.

Dalam Sciter saya telah membuat tes dengan mengimplementasikan inti jQurey penuh yang cukup banyak secara native. Pada tugas-tugas praktis seperti ScIDE (IDE terbuat dari HTML / CSS / Script) saya percaya solusi seperti itu bekerja secara signifikan lebih baik daripada optimasi VM.

Seperti yang telah disebutkan orang lain, Python memiliki kompiler JIT yang performan dalam bentuk PyPy .

Membuat tolok ukur yang berarti selalu halus, tetapi kebetulan saya memiliki tolok ukur sederhana K-means yang ditulis dalam berbagai bahasa - Anda dapat menemukannya di sini . Salah satu kendala adalah bahwa semua bahasa harus menerapkan algoritma yang sama dan harus berusaha untuk menjadi sederhana dan idiomatik (sebagai lawan dioptimalkan untuk kecepatan). Saya telah menulis semua implementasinya, jadi saya tahu saya belum selingkuh, walaupun saya tidak dapat mengklaim untuk semua bahasa bahwa apa yang saya tulis adalah idiomatik (saya hanya memiliki pengetahuan yang lewat tentang beberapa di antaranya).

Saya tidak mengklaim kesimpulan pasti, tetapi PyPy adalah salah satu implementasi tercepat yang saya dapatkan, jauh lebih baik daripada Node. CPython, sebaliknya, berada di ujung peringkat paling lambat.

Pernyataan itu tidak sepenuhnya benar

Sama seperti V8 hanyalah implementasi untuk JS, CPython hanyalah satu implementasi untuk Python. Pypy memiliki kinerja yang cocok dengan V8 .

Juga, ada masalah kinerja yang dirasakan: karena V8 secara asli tidak memblokir, dev Web mengarah ke proyek yang lebih berkinerja karena Anda menyimpan IO menunggu. Dan V8 terutama digunakan untuk dev Web di mana IO adalah kuncinya, sehingga mereka membandingkannya dengan proyek serupa. Tetapi Anda dapat menggunakan Python di banyak, banyak area selain web dev. Dan Anda bahkan dapat menggunakan ekstensi C untuk banyak tugas, seperti perhitungan ilmiah atau enkripsi, dan mengolah data dengan perf yang menyala-nyala.

Tetapi di web, sebagian besar proyek Python dan Ruby yang populer sedang diblokir. Python, khususnya, memiliki warisan standar WSGI yang sinkron, dan kerangka kerja seperti Django yang terkenal didasarkan padanya.

Anda dapat menulis Python asinkron (seperti dengan Twisted, Tornado, gevent atau asyncio) atau Ruby. Tapi itu tidak sering dilakukan. Alat terbaik masih memblokir.

Namun, mereka adalah beberapa alasan mengapa implementasi default di Ruby dan Python tidak secepat V8.

Pengalaman

Seperti Jorg W Mittag tunjukkan, orang-orang yang bekerja pada V8 adalah jenius VM. Python adalah dev oleh sekelompok orang yang penuh gairah, sangat baik dalam banyak domain, tetapi tidak mengkhususkan diri dalam tuning VM.

Sumber daya

Yayasan Python Software memiliki sedikit uang: kurang dari 40rb dalam setahun untuk berinvestasi di Python. Ini agak gila ketika Anda berpikir pemain besar seperti Google, Facebook atau Apple semuanya menggunakan Python, tapi itu kebenarannya: kebanyakan pekerjaan dilakukan secara gratis. Bahasa yang mendukung Youtube dan ada sebelum Jawa telah dibuat oleh para relawan.

Mereka adalah sukarelawan yang berdedikasi dan berdedikasi, tetapi ketika mereka mengidentifikasi mereka membutuhkan lebih banyak jus di lapangan, mereka tidak dapat meminta 300rb untuk menyewa spesialis tingkat atas untuk bidang keahlian ini. Mereka harus mencari-cari seseorang yang akan melakukannya secara gratis.

Sementara ini berhasil, itu berarti Anda harus sangat berhati-hati dengan prioritas Anda. Oleh karena itu, sekarang kita perlu melihat:

Tujuan

Bahkan dengan fitur modern terbaru, menulis Javascript sangat buruk. Anda memiliki masalah pelingkupan, sangat sedikit koleksi, manipulasi string dan array yang mengerikan, hampir tidak ada stdlist selain tanggal, matematika dan regex, dan tidak ada gula sintaksis bahkan untuk operasi yang sangat umum.

Namun di V8, Anda punya kecepatan.

Ini karena, kecepatan adalah tujuan utama Google, karena ini menjadi penghambat untuk perenderan halaman di Chrome.

Dalam Python, kegunaan adalah tujuan utama. Karena itu hampir tidak pernah menjadi hambatan pada proyek. Sumber daya yang langka di sini adalah waktu pengembang. Ini dioptimalkan untuk pengembang.

Karena implementasi JavaScript tidak perlu peduli dengan kompatibilitas bindings mereka.

Sampai saat ini satu-satunya pengguna implementasi JavaScript adalah browser web. Karena persyaratan keamanan, hanya vendor browser web yang memiliki hak istimewa untuk memperluas fungsionalitas dengan menulis binding ke runtimes. Dengan demikian tidak perlu menjaga agar API C dari binding tetap kompatibel, diizinkan untuk meminta pengembang browser web memperbarui kode sumber mereka saat runtime JavaScript berevolusi; mereka bekerja bersama-sama. Bahkan V8, yang merupakan latecomer untuk game, dan juga dipimpin oleh pengembang yang sangat berpengalaman, telah mengubah API karena menjadi lebih baik.

OTOH Ruby digunakan (terutama) di sisi server. Banyak ekstensi ruby ​​populer ditulis sebagai binding C (pertimbangkan driver RDBMS). Dengan kata lain, Ruby tidak akan pernah berhasil tanpa mempertahankan kompatibilitas.

Saat ini, perbedaannya masih ada sampai batas tertentu. Pengembang yang menggunakan node.js mengeluh bahwa sulit untuk menjaga ekstensi asli mereka tetap kompatibel, karena V8 mengubah API dari waktu ke waktu (dan itulah salah satu alasan node.js telah bercabang dua). Ruby IIRC masih mengambil pendekatan yang jauh lebih konservatif dalam hal ini.

V8 cepat karena JIT, Crankshaft, tipe inferencer dan kode yang dioptimalkan data. Pointer yang ditandai, penandaan ganda NaN. Dan tentu saja itu tidak optimalisasi kompiler normal di tengah.

Mesin ruby, python dan perl yang polos tidak melakukan keduanya, hanya optimasi dasar kecil.

Satu-satunya vm utama yang mendekati adalah luajit, yang bahkan tidak melakukan inferensi tipe, pelipatan konstan, penandaan NaN atau bilangan bulat, tetapi menggunakan kode kecil dan struktur data yang sama, tidak setemak bahasa yang buruk. Dan bahasa dinamis prototipe saya, ramuan dan p2 memiliki fitur yang sama seperti luajit, dan mengungguli v8. Dengan sistem jenis opsional, "pengetikan bertahap", Anda dapat dengan mudah mengungguli v8, karena Anda dapat mem-bypass crankshaft. Lihat panah.

Backend dioptimalkan dikenal, seperti pypy atau jruby masih menderita berbagai teknik over-engineering.