Ce împiedică Ruby și Python să obțină viteza Javascript V8?

Există caracteristici ale Ruby sau Python care împiedică implementarea optimizărilor (de exemplu, caching în linie) pe care motorul V8 le are?

Python este co-dezvoltat de cei de la Google, așa că nu ar trebui să fie blocat de brevetele software.

Sau acesta este mai degrabă o problemă a resurselor investite în proiectul V8 de Google.

Răspuns #1

Ce împiedică Ruby și Python să obțină viteza Javascript V8?

Nimic.

Ei bine, bine: bani. (Și timp, oameni, resurse, dar dacă ai bani, le poți cumpăra.)

V8 are o echipă de ingineri străluciți, foarte specializați și cu multă experiență (și, prin urmare, foarte bine plătiți) care lucrează la el, având decenii de experiență (vorbesc despre experiența individuală - colectiv vorbind, este mai degrabă vorba de secole) în crearea de motoare de execuție de înaltă performanță pentru limbaje OO dinamice. Practic, sunt aceiași oameni care au creat și Sun HotSpot JVM (printre mulți alții).

Lars Bak, dezvoltatorul principal, lucrează practic la mașini virtuale de 25 de ani (și toate acele mașini virtuale au condus la V8), ceea ce reprezintă practic întreaga sa viață (profesională). Unii dintre oamenii care scriu mașini virtuale Ruby nici măcar nu au 25 de ani.

Există vreun atribut Ruby/Python care împiedică implementarea optimizărilor (de exemplu, caching inline) pe care le are motorul V8?

Având în vedere că cel puțin IronRuby, JRuby, MagLev, MacRuby și Rubinius au fie caching inline monomorf (IronRuby), fie polimorf, răspunsul este evident nu.

Implementările moderne de Ruby fac deja o mulțime de optimizări. De exemplu, pentru anumite operații, clasa Hash a Rubinius este mai rapidă decât cea a YARV. Acum, asta nu sună extraordinar de interesant până nu realizezi că clasa Hash a Rubinius este implementată 100% în Ruby pur, în timp ce cea a YARV este implementată 100% în C optimizat manual.

Deci, cel puțin în unele cazuri, Rubinius poate genera cod mai bun decât GCC!

Sau acesta este mai degrabă o problemă a resurselor investite în proiectul V8 de Google.

Da. Nu doar Google. Linia de cod sursă a V8 are acum 25 de ani. Oamenii care lucrează la V8 au creat, de asemenea, VM-ul Self (până în prezent unul dintre cele mai rapide motoare de execuție pentru limbaje dinamice OO vreodată create), VM-ul Animorphic Smalltalk (până în prezent unul dintre cele mai rapide motoare de execuție Smalltalk vreodată create), JVM-ul HotSpot (cea mai rapidă JVM vreodată creată, probabil cea mai rapidă VM în general) și OOVM (unul dintre cele mai eficiente VM-uri Smalltalk vreodată create).

De fapt, Lars Bak, dezvoltatorul principal al V8, a lucrat la fiecare dintre acestea, plus câteva altele.

Răspunsul #2

Există mult mai mult impuls pentru a optimiza foarte mult interpretoarele JavaScript, motiv pentru care vedem atât de multe resurse investite în ele între Mozilla, Google și Microsoft. JavaScript trebuie descărcat, analizat, compilat și rulat în timp real, în timp ce un om (de obicei nerăbdător) așteaptă, trebuie să ruleze ÎN TIMP CE o persoană interacționează cu el și face acest lucru într-un mediu necontrolat la capătul clientului care ar putea fi un computer, un telefon sau un toaster. Trebuie să fie eficient pentru a putea funcționa eficient în aceste condiții.

Python și Ruby rulează într-un mediu controlat de către dezvoltator/deployer. Un server sau sistem desktop puternic, unde factorul limitativ va fi de obicei lucruri precum memoria sau I/O-ul pe disc și nu timpul de execuție. Sau acolo unde pot fi utilizate optimizări externe motorului, cum ar fi caching-ul. Pentru aceste limbaje probabil că are mai mult sens să te concentrezi pe setul de caracteristici al limbajului și al bibliotecilor decât pe optimizarea vitezei.

Beneficiul secundar al acestui lucru este că avem două motoare JavaScript open source de înaltă performanță care pot fi și sunt reutilizate pentru tot felul de aplicații, cum ar fi Node.js.

Răspunsul #3

O mare parte din asta are legătură cu comunitatea. Python și Ruby, în mare parte, nu au sprijin corporativ. Nimeni nu este plătit să lucreze full-time la Python și Ruby (și cu atât mai puțin să fie plătit să lucreze tot timpul la CPython sau MRI). V8, pe de altă parte, este sprijinit de cea mai puternică companie IT din lume.

Mai mult, V8 poate fi mai rapid deoarece singurul lucru care contează pentru oamenii de la V8 este interpretatorul -- ei nu au o bibliotecă standard pe care să lucreze, nu au griji legate de designul limbajului. Ei doar scriu interpretatorul. Atât.

Nu are nicio legătură cu legea proprietății intelectuale. De asemenea, Python nu este co-dezvoltat de angajați Google (creatorul său lucrează acolo împreună cu câțiva alți contribuitori, dar nu sunt plătiți să lucreze la Python).

Un alt obstacol pentru viteza Python este Python 3. Adoptarea sa pare a fi principala preocupare a dezvoltatorilor limbajului -- până în punctul în care au înghețat dezvoltarea noilor caracteristici ale limbajului până când alte implementări vor ajunge din urmă.

Să trecem la detalii tehnice, nu știu prea multe despre Ruby, dar Python are o serie de locuri unde ar putea fi folosite optimizări (și Unladen Swallow, un proiect Google, a început să le implementeze înainte de a fi abandonat). Iată câteva dintre optimizările pe care le-au planificat. Aș putea vedea Python ajungând la viteza V8 în viitor dacă s-ar implementa un JIT de tip PyPy pentru CPython, dar acest lucru nu pare probabil în anii următori (accentul acum este pe adoptarea Python 3, nu pe un JIT).

Mulți cred, de asemenea, că Ruby și Python ar putea beneficia enorm de pe urma eliminării blocărilor lor globale ale interpretorului respective.

Trebuie să înțelegi, de asemenea, că Python și Ruby sunt ambele limbaje mult mai grele decât JS - ele oferă mult mai multe în ceea ce privește biblioteca standard, caracteristicile limbajului și structură. Sistemul de clase al orientării pe obiecte adaugă singur o greutate considerabilă (într-un mod bun, cred). Aproape că mă gândesc la Javascript ca la un limbaj conceput să fie integrat, ca Lua (și în multe privințe, ele sunt similare). Ruby și Python au un set mult mai bogat de caracteristici, iar această expresivitate va veni de obicei cu costul vitezei.

Răspunsul #4

Performanța nu pare să fie un focus major al dezvoltatorilor de bază Python, care par să considere că „suficient de rapid” este suficient, și că funcțiile care ajută programatorii să fie mai productivi sunt mai importante decât funcțiile care ajută calculatoarele să ruleze codul mai repede.

Într-adevăr, totuși, a existat un proiect Google (acum abandonat), unladen-swallow, pentru a produce un interpret Python mai rapid compatibil cu interpretul standard. PyPy este un alt proiect care intenționează să producă un Python mai rapid. Există, de asemenea, Psyco, precursorul PyPy, care poate oferi creșteri de performanță multor scripturi Python fără a schimba întregul interpret, și Cython, care vă permite să scrieți biblioteci C de înaltă performanță pentru Python folosind ceva foarte asemănător cu sintaxa Python.

Răspunsul #5

Întrebare înșelătoare. V8 este o implementare JIT (un compilator just in time) a JavaScript și în cea mai populară implementare non-browser, Node.js, este construit în jurul unui event loop. CPython nu este JIT și nici nu folosește evenimente. Dar acestea există în Python, cel mai adesea în proiectul PyPy - un JIT compatibil cu CPython 2.7 (și în curând 3.0+). Și există o mulțime de biblioteci server care folosesc evenimente, cum ar fi Tornado, de exemplu. Există teste reale între PyPy care rulează Tornado și Node.js, iar diferențele de performanță sunt mici.