Що блокує Ruby, Python для отримання швидкості Javascript V8? [зачинено]

Чи є якісь функції Ruby / Python, які блокують реалізацію оптимізацій (наприклад, вбудоване кешування ) двигуна V8?

Python розробляється хлопцями Google, тому його не слід блокувати патентами на програмне забезпечення.

Або це скоріше питання ресурсів, вкладених у проект V8 від Google.

Що блокує Ruby, Python для отримання швидкості Javascript V8?

Нічого.

Ну добре: гроші. (І час, люди, ресурси, але якщо у вас є гроші, їх можна придбати.)

V8 має команду блискучих, високоспеціалізованих, досвідчених (і, таким чином, високооплачуваних) інженерів, які працюють над нею, які мають десятиліття досвіду (я говорю індивідуально - колективно це більше як століття) у створенні високопродуктивної роботи двигуни для динамічних мов OO. Це в основному ті самі люди, які також створили JVM Sun HotSpot (серед багатьох інших).

Ларс Бак, провідний розробник, буквально працює над VM протягом 25 років (і всі ці VM привели до V8), що в основному є його всім (професійним) життям. Деяким людям, які пишуть рубінові відеомашини, немає навіть 25 років.

Чи є якісь функції Ruby / Python, які блокують реалізацію оптимізацій (наприклад, вбудоване кешування) двигуна V8?

Зважаючи на те, що принаймні IronRuby, JRuby, MagLev, MacRuby та Rubinius мають або мономорфне (IronRuby), або поліморфне вбудоване кешування, відповідь, очевидно, ні.

Сучасні реалізації Ruby вже роблять велику оптимізацію. Наприклад, для певних операцій Hashклас Рубінія швидший, ніж у YARV. Тепер це не здається надзвичайно захоплюючим, поки ви не зрозумієте, що Hashклас Рубінія реалізований у 100% чистому Ruby, тоді як YARV реалізований у 100% оптимізованому руці C.

Так, принаймні в деяких випадках Рубіній може генерувати кращий код, ніж GCC!

Або це скоріше питання ресурсів, вкладених у проект V8 від Google.

Так. Не лише Google. Ряд вихідного коду V8 вже 25 років. Люди, які працюють над V8, також створили Self VM (на сьогоднішній день один із найшвидших динамічних механізмів виконання мови OO, що коли-небудь створений), Animorphic Smalltalk VM (на сьогоднішній день один з найшвидших двигунів виконання Smalltalk, коли-небудь створений), HotSpot JVM (найшвидший JVM, який коли-небудь створений, мабуть, найшвидший VM-період) та OOVM (одна з найефективніших віртуальних машин Smalltalk, коли-небудь створена).

Насправді Ларс Бак, провідний розробник V8, працював над кожною з них, а також кількома іншими.

Існує набагато більше поштовхів до оптимізації інтерпретаторів JavaScript, тому ми бачимо, що між ними Mozilla, Google та Microsoft вкладається так багато ресурсів. JavaScript потрібно завантажувати, розбирати, компілювати та запускати в режимі реального часу, поки на нього чекає (як правило, нетерпляча) людина, вона повинна запускатись, поки людина взаємодіє з нею, і це робить це в неконтрольованому клієнтові оточення, яке може бути комп’ютером, телефоном або тостером. МАЄ бути ефективним, щоб ефективно працювати в цих умовах.

Python та Ruby виконуються в середовищі, контрольованому розробником / розробником. Файливий сервер чи настільна система, де обмежуючим фактором будуть такі речі, як введення / виведення пам'яті чи диска, а не час виконання. Або там, де можна використовувати немоторні оптимізації, такі як кешування. Для цих мов, мабуть, має сенс зосередитись на мові та набір функцій бібліотеки через оптимізацію швидкості.

Побічною перевагою цього є те, що у нас є два високоефективні двигуни з відкритим кодом JavaScript, які можна і переробляють для будь-яких додатків, таких як Node.js.

Добра частина цього стосується громади. Python та Ruby здебільшого не мають корпоративного забезпечення. Ніхто не отримує оплату за роботу над Python та Ruby на повний робочий день (і особливо вони не отримують зарплату за роботу над CPython або MRI весь час). З іншого боку, V8 підтримується найпотужнішою ІТ-компанією у світі.

Крім того, V8 може бути швидшим, тому що єдине, що важливе для людей V8, - це перекладач - у них немає стандартної бібліотеки, над якою можна працювати, і жодних проблем щодо мовного дизайну. Вони просто пишуть перекладача. Це воно.

Це не має нічого спільного з законом про інтелектуальну власність. Також хлопці Google не розробляються спільно з Python (його створювач працює разом з кількома іншими комітетами, але вони не отримують зарплату за роботу над Python).

Ще одна перешкода для швидкості роботи Python - це Python 3. Його прийняття, здається, є головним питанням розробників мови - до того, що вони заморозили розробку нових мовних функцій, поки інші реалізації не наздогнали.

Щодо технічних деталей, я мало знаю про Ruby, але Python має ряд місць, де можна було б використовувати оптимізації (і Unladen Swallow, проект Google, почав їх реалізовувати, перш ніж кусати пил). Ось кілька оптимізацій, які вони планували . Я міг би бачити, як Python набирає швидкість V8 у майбутньому, якщо JIT a la PyPy буде впроваджений для CPython, але це не здається ймовірним у найближчі роки (фокус зараз - прийняття Python 3, а не JIT).

Багато людей також вважають, що Ruby та Python могли б отримати величезну користь від усунення відповідних глобальних переводів інтерпретаторів .

Ви також повинні розуміти, що Python та Ruby - це набагато важчі мови, ніж JS - вони набагато більше забезпечують стандартну бібліотеку, особливості мови та структуру. Сама класова система орієнтації на об'єкт додає великої ваги (я гадаю). Я майже вважаю Javascript як мову, розроблену для вбудовування, як Lua (і багато в чому вони схожі). У Ruby та Python є набагато більш багатий набір функцій, і ця виразність зазвичай приходить ціною швидкості.

Ефективність, здається, не є головним акцентом основних розробників Python, які, здається, вважають, що "досить швидкий" є досить хорошим, а функції, які допомагають програмістам бути більш продуктивними, важливіші, ніж функції, які допомагають комп'ютерам швидше працювати з кодом.

Дійсно, однак, існував (покинутий) проект Google, не накладений , щоб створити швидший інтерпретатор Python, сумісний зі стандартним перекладачем. PyPy - ще один проект, який має намір створити більш швидкий Python. Є також Psyco , попередник PyPy, який може забезпечити підвищення продуктивності для багатьох сценаріїв Python, не змінюючи весь інтерпретатор, і Cython , який дозволяє писати високопродуктивні бібліотеки C для Python, використовуючи щось дуже схоже на синтаксис Python.

Оманливе запитання. V8 - реалізація JavaScript JIT (щойно вчасно), і в його найпопулярнішій не браузерній реалізації Node.js він побудований навколо циклу подій. CPython - це не JIT, і навіть не враховується. Але вони існують у Python, найчастіше в проекті PyPy - це сумісний з JYT сумісний CPython 2.7 (і незабаром має бути 3.0+). Наприклад, є безліч парних бібліотек серверів, таких як Торнадо, наприклад. Тести реального світу існують між PyPy під керуванням Tornado проти Node.js, а відмінності у продуктивності незначні.

Я щойно стикався з цим питанням, і є велика технічна причина різниці в продуктивності, про яку не згадувалося. У Python є дуже велика екосистема потужних розширень програмного забезпечення, але більшість цих розширень написані на C або інших мовах низького рівня для продуктивності та сильно прив'язані до API CPython.

Існує маса відомих методик (JIT, сучасний сміттєзбірник тощо), які можна використовувати для прискорення впровадження CPython, але всі потребують суттєвих змін у API, порушуючи більшість розширень у процесі. CPython був би швидшим, але багато того, що робить Python таким привабливим (великий пакет програм), буде втрачено. Справа в тому, що є кілька швидших реалізації Python, але вони мають малу тягу порівняно з CPython.

Я вважаю, що через різні пріоритети дизайну та використання цілей конкретного випадку.

Загалом, основна мета скриптових (також динамічних) мов - це "клей" між викликами нативних функцій. І ці основні функції повинні: а) охоплювати найбільш критичні / найчастіше використовувані області; і b) бути максимально ефективними.

Ось приклад: Сортування jQuery змушує замерзання if Safari Замороження там викликається надмірним використанням викликів get-by-selector. Якщо get-by-селектор буде реалізований у власному коді та ефективно, такої проблеми взагалі не буде.

Розглянемо демонстрацію променів-променів, яка часто використовується для демонстрації V8. У світі Python він може бути реалізований у рідному коді, оскільки Python надає всі засоби для вбудованих розширень. Але у царині V8 (пісочниця на стороні клієнта) у вас немає інших варіантів, а не зробити VM максимально ефективним [суб]. І тому єдиний варіант бачити реалізацію променів-відслідковувачів є за допомогою коду сценарію.

Так різні пріоритети та мотивації.

У Sciter я зробив тест, реалізувавши майже повністю повне ядро ​​jQurey. У таких практичних завданнях, як ScIDE (IDE, що складається з HTML / CSS / Script), я вважаю, що таке рішення працює значно краще, ніж будь-які оптимізації VM.

Як уже згадували інші, Python має виконавчий компілятор JIT у формі PyPy .

Створення значущих орієнтирів завжди тонке, але у мене, мабуть, є простий орієнтир K-засобів, написаний різними мовами - ви можете знайти його тут . Одним із обмежень було те, що різні мови повинні реалізовувати один і той же алгоритм і прагнути бути простими та ідіоматичними (на відміну від оптимізованих для швидкості). Я написав усі реалізації, тому знаю, що не обдурив, хоча не можу стверджувати, що для всіх мов це те, що я написав, ідіоматичне (про деякі з них я лише знаю, що переходять).

Я не претендую на будь-який остаточний висновок, але PyPy був серед найшвидших реалізацій, які я отримав, набагато краще, ніж Node. Натомість CPython опинився у найповільнішому кінці рейтингу.

Заява не зовсім вірна

Як і V8 - це лише реалізація для JS, CPython - це лише одна реалізація для Python. У Pypy є вистави, що відповідають V8 .

Крім того, існує проблема сприйнятої продуктивності: оскільки V8 спочатку не блокує, веб-розробник приводить до більш ефективних проектів, тому що ви економите очікування IO. І V8 використовується в основному для веб-розробників, де ключовий IO, тому вони порівнюють його з подібними проектами. Але ви можете використовувати Python у багатьох, багатьох інших областях, ніж веб-розробник. Ви навіть можете використовувати розширення C для безлічі завдань, таких як наукові обчислення чи шифрування, а також стискання даних із яскравими перф.

Але в Інтернеті найпопулярніші проекти Python та Ruby блокуються. Python, особливо, має спадщину синхронного стандарту WSGI, і на ньому базуються рамки, як відомий Django.

Ви можете написати асинхронний Python (наприклад, з Twisted, Tornado, gevent або asyncio) або Ruby. Але це робиться не часто. Найкращі інструменти все ще блокуються.

Однак вони є деякими причинами, по яких реалізація за замовчуванням у Ruby та Python не настільки швидка, як V8.

Досвід

Як зазначав Йорг У Міттаг, хлопці, які працюють на V8, - генії VM. Python розроблений купою пристрасних людей, дуже хороший у багатьох областях, але не настільки спеціалізований у налаштуванні VM.

Ресурси

Фонд Python Software має дуже мало грошей: менше 40 тис. Доларів на рік інвестувати в Python. Це якось божевільно, коли ви думаєте, що великі гравці, такі як Google, Facebook чи Apple, всі використовують Python, але це некрасива правда: більшість робіт робиться безкоштовно. Мова, яка використовує Youtube та існувала ще до того, як Ява була розроблена волонтерами.

Вони розумні і віддані добровольці, але коли вони виявлять, що їм потрібно більше соку в галузі, вони не можуть попросити 300 тис. Наймати найвищого спеціаліста для цієї галузі. Вони повинні оглянути когось, хто зробив би це безкоштовно.

Хоча це працює, це означає, що ви повинні бути дуже уважні до своїх пріоритетів. Отже, зараз нам потрібно подивитися:

Цілі

Навіть з найновішими сучасними функціями, написання Javascript жахливо. У вас є проблеми зі складанням рахунків, дуже мало колекцій, жахливі маніпуляції з рядками та масивами, майже немає списків stdlist, окрім дати, математики та регулярних виразів, а також синтаксичного цукру навіть для дуже поширених операцій.

Але у V8 у вас швидкість.

Це тому, що швидкість була основною метою для Google, оскільки це вузьке місце для візуалізації сторінок у Chrome.

У Python основна мета - зручність використання. Тому що це майже не вузьке місце на проекті. Дефіцитний ресурс тут - це час для розробників. Це оптимізовано для розробника.

Оскільки реалізація JavaScript не повинна дбати про зворотну сумісність їх прив'язок.

До недавнього часу єдиними користувачами реалізацій JavaScript були веб-браузери. Зважаючи на вимоги безпеки, лише постачальники веб-браузерів мали право розширити функціональність, написавши прив'язки до виконання. Таким чином, не було необхідності підтримувати сумісність API API прив'язки назад, було дозволено вимагати від розробників веб-браузера оновлення свого вихідного коду в міру розвитку часу виконання JavaScript; вони все одно працювали разом. Навіть V8, який був запізнілим у грі, а також керував дуже досвідчений розробник, змінив API, як він став кращим.

OTOH Ruby використовується (головним чином) на стороні сервера. Багато популярних розширень рубіну записуються як прив'язка C (розглянемо драйвер RDBMS). Іншими словами, Ruby ніколи б не досяг успіху без збереження сумісності.

Сьогодні різниця все ще існує певною мірою. Розробники, що використовують node.js, скаржаться на те, що важко підтримувати їх рідні розширення назад сумісними, оскільки V8 змінює API з часом (і це одна з причин, коли node.js був роздвоєний). Рубін IIRC все ще застосовує набагато більш консервативний підхід у цьому відношенні.

V8 швидкий завдяки JIT, Crankshaft, типу inferencer та оптимізованому коду коду. Позначені мітки, NaN-позначення пар. І звичайно це робить звичайні оптимізації компілятора в середині.

Прості рубінові, пітонні та perl двигуни не роблять жодного з цих, лише незначні базові оптимізації.

Єдиний основний vm, який наближається, - це luajit, який навіть не робить висновок, постійне складання, NaN-позначення та цілі числа, але використовує схожі невеликі структури коду та даних, не такі жирні, як погані мови. І мої прототипи динамічних мов, зілля та p2 мають схожі функції як luajit, так і перевершують v8. З додатковою системою типу "поступового набору тексту" ви зможете легко перевершити v8, оскільки можете обійти колінчастий вал. Дивіться дротик.

Відомі оптимізовані засоби, такі як піпі або дрюбі, як і раніше страждають від різних методів інженерії.