Что блокирует Ruby, Python для получения скорости Javascript V8? [закрыто]

Существуют ли какие-либо функции Ruby / Python, которые блокируют реализацию оптимизаций (например, встроенное кэширование ) в движке V8?

Python разработан совместно парнями из Google, поэтому он не должен блокироваться патентами на программное обеспечение.

Или это скорее вопрос ресурсов, вложенных в проект V8 компанией Google.

Что блокирует Ruby, Python для получения скорости Javascript V8?

Ничего.

Ну да ладно: деньги. (И время, люди, ресурсы, но если у вас есть деньги, вы можете их купить.)

В V8 работает команда блестящих, высокоспециализированных, высококвалифицированных (и, следовательно, высокооплачиваемых) инженеров, которые имеют многолетний опыт (я говорю индивидуально - в совокупности это больше похоже на столетия) в создании высокопроизводительного исполнения движки для динамических ОО языков. В основном это те же люди, которые также создали JVM Sun HotSpot (среди многих других).

Ларс Бак, ведущий разработчик, буквально работает над виртуальными машинами в течение 25 лет (и все эти виртуальные машины ведут к V8), что в основном и является его (профессиональной) жизнью. Некоторым из людей, пишущих виртуальные машины Ruby, нет даже 25 лет.

Существуют ли какие-либо функции Ruby / Python, которые блокируют реализацию оптимизаций (например, встроенное кэширование) в движке V8?

Учитывая, что по крайней мере IronRuby, JRuby, MagLev, MacRuby и Rubinius имеют либо мономорфное (IronRuby), либо полиморфное встроенное кэширование, ответ, очевидно, отрицательный.

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

Так что, по крайней мере, в некоторых случаях Rubinius может генерировать лучший код, чем GCC!

Или это скорее вопрос ресурсов, вложенных в проект V8 компанией Google.

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

Фактически, Ларс Бак, ведущий разработчик V8, работал над каждым из них, а также над несколькими другими.

Существует гораздо больше стимулов для высокой оптимизации интерпретаторов JavaScript, поэтому мы видим, что в них вкладывается так много ресурсов между Mozilla, Google и Microsoft. JavaScript должен быть загружен, проанализирован, скомпилирован и запущен в режиме реального времени, пока его ждет (обычно нетерпеливый) человек, он должен запускаться, пока с ним взаимодействует человек, и делает это в неконтролируемой клиентской части среда, которая может быть компьютером, телефоном или тостером. Он должен быть эффективным, чтобы эффективно работать в этих условиях.

Python и Ruby работают в среде, контролируемой разработчиком / развертывателем. Высокопроизводительная серверная или настольная система, в которой ограничивающим фактором будут такие вещи, как память или дисковый ввод-вывод, а не время выполнения. Или где могут быть использованы не-движковые оптимизации, такие как кэширование. Для этих языков, вероятно, имеет смысл сосредоточиться на языковом и библиотечном наборе функций по оптимизации скорости.

Дополнительным преимуществом этого является то, что у нас есть два великолепных высокопроизводительных движка JavaScript с открытым исходным кодом, которые могут и переопределяются для всех видов приложений, таких как Node.js.

Хорошая часть этого имеет отношение к сообществу. Python и Ruby по большей части не имеют корпоративной поддержки. Никто не платит за работу на Python и Ruby полный рабочий день (и им особенно не платят за работу на CPython или MRI все время). V8, с другой стороны, поддерживается самой мощной IT-компанией в мире.

Кроме того, V8 может быть быстрее, потому что единственное, что имеет значение для людей V8, - это переводчик - у них нет стандартной библиотеки для работы, нет проблем с языковым дизайном. Они просто пишут переводчик. Вот и все.

Это не имеет ничего общего с законом об интеллектуальной собственности. Также Python не разрабатывается совместно ребятами из Google (его создатель работает там вместе с несколькими другими коммиттерами, но им не платят за работу над Python).

Еще одно препятствие для скорости Python - это Python 3. Его принятие, по-видимому, является главной заботой разработчиков языка - до такой степени, что они заморозили разработку новых языковых функций, пока другие реализации не догонят.

Что касается технических деталей, я не знаю много о Ruby, но в Python есть ряд мест, где можно использовать оптимизации (и Unladen Swallow, проект Google, начал реализовывать их, прежде чем кусать пыль). Вот некоторые из запланированных оптимизаций . Я мог бы увидеть Python, набирающий скорость V8 в будущем, если JIT а-ля 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 - это реализация JIT (компилятор точно в срок) JavaScript, а в своей самой популярной не браузерной реализации Node.js она построена вокруг цикла обработки событий. CPython не является JIT и не выравнивается. Но они существуют в Python чаще всего в проекте PyPy - Jit, совместимом с CPython 2.7 (и скоро будет 3.0+). И есть множество серверных библиотек, таких как Tornado, например. Между PyPy и Tornado vs Node.js существуют реальные тесты, и различия в производительности незначительны.

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

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

Из-за разных приоритетов дизайна и целей использования я верю.

В общем, основная цель языков сценариев (или динамических) языков - быть «связующим звеном» между вызовами нативных функций. И эти собственные функции должны а) охватывать наиболее важные / часто используемые области и б) быть максимально эффективными.

Вот пример: сортировка jQuery, приводящая к зависанию iOS Safari . Замораживание вызвано чрезмерным использованием вызовов get-by-selector. Если бы get-by-selector был бы реализован в нативном коде, и эффективно это не было бы такой проблемой вообще.

Рассмотрим демонстрацию ray-tracer, которая часто используется для демонстрации V8. В мире Python это может быть реализовано в собственном коде, поскольку Python предоставляет все возможности для собственных расширений. Но в области V8 (песочница на стороне клиента) у вас нет других вариантов, кроме как сделать виртуальную машину максимально эффективной. И поэтому единственный вариант увидеть реализацию ray-tracer - это использование кода скрипта.

Так разные приоритеты и мотивы.

В Sciter я сделал тест, реализовав практически полное ядро ​​jQurey. В практических задачах, таких как ScIDE (IDE из HTML / CSS / Script), я считаю, что такое решение работает значительно лучше, чем любая оптимизация виртуальной машины.

Как уже упоминали другие, Python имеет производительный JIT-компилятор в форме PyPy .

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

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

Утверждение не совсем верно

Так же, как V8 - просто реализация для JS, CPython - только одна реализация для Python. Pypy имеет характеристики, соответствующие V8 .

Кроме того, существует проблема воспринимаемой производительности: поскольку V8 изначально не блокируется, Web dev приводит к более производительным проектам, поскольку вы экономите время ожидания ввода-вывода. А V8 в основном используется для веб-разработки, где IO является ключевым, поэтому они сравнивают его с аналогичными проектами. Но вы можете использовать Python во многих других областях, кроме веб-разработчика. И вы даже можете использовать расширения C для множества задач, таких как научные вычисления или шифрование, и обрабатывать данные с невероятной скоростью.

Но в Интернете большинство популярных проектов Python и Ruby блокируются. Python, в частности, обладает наследием синхронного стандарта WSGI, и на его основе основаны фреймворки, такие как знаменитый Django.

Вы можете написать асинхронный Python (как с Twisted, Tornado, Gevent или Asyncio) или Ruby. Но это делается не часто. Лучшие инструменты все еще блокируют.

Однако они являются некоторыми причинами того, почему реализации по умолчанию в Ruby и Python не такие быстрые, как V8.

Опыт

Как отметил Йорг Миттаг, парни, работающие над V8, являются гениями виртуальных машин. Python - это группа увлеченных людей, которые хорошо разбираются во многих областях, но не настолько специализированы в настройке виртуальных машин.

Ресурсы

У фонда Python Software очень мало денег: менее 40 тыс. В год для инвестиций в Python. Это довольно безумно, когда вы думаете, что крупные игроки, такие как Google, Facebook или Apple, все используют Python, но это ужасная правда: большая часть работы выполняется бесплатно. Язык, который поддерживает YouTube и существовал до Java, был создан вручную добровольцами.

Они умные и преданные своему делу добровольцы, но когда они обнаруживают, что им нужно больше сока в поле, они не могут попросить 300 тысяч, чтобы нанять высококлассного специалиста для этой области знаний. Они должны искать кого-то, кто сделал бы это бесплатно.

Хотя это работает, это означает, что вы должны быть очень осторожны в своих приоритетах. Следовательно, теперь нам нужно взглянуть на:

Цели

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

Но в V8 у вас есть скорость.

Это потому, что скорость была главной целью для Google, так как это узкое место для рендеринга страниц в Chrome.

В Python юзабилити является основной целью. Потому что это почти никогда не является узким местом в проекте. Недостаточным ресурсом здесь является время разработки. Это оптимизировано для разработчика.

Поскольку реализации JavaScript не должны заботиться об обратной совместимости их привязок.

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

OTOH Ruby используется (в основном) на стороне сервера. Многие популярные расширения ruby ​​написаны как привязки C (рассмотрим драйвер RDBMS). Другими словами, Ruby никогда бы не преуспел без поддержки совместимости.

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

V8 работает быстро благодаря JIT, Crankshaft, типизатору и оптимизированному коду коду. Помеченные указатели, NaN-теги двойников. И, конечно, он выполняет обычную оптимизацию компилятора в середине.

Простые движки ruby, python и perl не делают ни того, ни другого, только незначительные базовые оптимизации.

Единственный крупный vm, который подходит близко, - это luajit, который даже не делает вывод типов, константное свертывание, NaN-тегирование или целые числа, но использует такой же небольшой код и структуры данных, не такие жирные, как плохие языки. А мои прототипы динамических языков, potion и p2 имеют те же функции, что и luajit, и превосходят v8. С опциональной системой типов «постепенная печать» вы можете легко превзойти v8, поскольку можете обойти коленчатый вал. Смотри дротик.

Известные оптимизированные бэкэнды, такие как pypy или jruby, все еще страдают от различных чрезмерных технических приемов.