Существуют ли какие-либо функции Ruby/Python, которые блокируют реализацию оптимизаций (например, встроенное кэширование). Двигатель V8 имеет?
Python совместно разрабатывается ребятами Google, поэтому он не должен быть заблокирован патентами на программное обеспечение.
Или это скорее вопрос ресурсов, внесенных Google в проект V8.
Что блокирует Ruby, Python, чтобы получить скорость Javascript V8?
Ничего.
Хорошо, ладно: деньги. (И время, люди, ресурсы, но если у вас есть деньги, вы можете их купить.)
В V8 есть команда блестящих, высокоспециализированных, высококвалифицированных (и, следовательно, высокооплачиваемых) инженеров, работающих над ней, которые имеют многолетний опыт (я говорю индивидуально и коллективно это больше, чем столетия) в создание высокопроизводительных механизмов выполнения для динамических языков OO. Они в основном те же люди, которые также создали JVM Sun HotSpot (среди многих других).
Ларс Бак, ведущий разработчик, буквально работает на виртуальных машинах в течение 25 лет (и все эти виртуальные машины довели до V8), что в основном является его всей (профессиональной) жизнью. Некоторым людям, которые пишут Ruby VM, даже не 25 лет.
Есть ли какие-либо функции Ruby/Python, которые блокируют реализацию оптимизаций (например, встроенное кэширование), двигатель V8 имеет?
Учитывая, что, по крайней мере, IronRuby, JRuby, MagLev, MacRuby и Rubinius имеют либо мономорфный (IronRuby), либо полиморфный встроенный кешинг, ответ явно отсутствует.
Современные Ruby-реализации уже делают много оптимизаций. Например, для некоторых операций класс Rubinius Hash выполняется быстрее, чем YARV. Теперь это не звучит ужасно интересно, пока вы не поймете, что класс Rubinius Hash реализован на 100% чистом Ruby, тогда как YARV реализован в 100% оптимизированном вручную C.
Итак, по крайней мере в некоторых случаях, Rubinius может генерировать более эффективный код, чем GCC!
Или это скорее вопрос ресурсов, внесенных в проект V8 компанией Google.
Да. Не только Google. Теперь исходный код V8 составляет 25 лет. Люди, которые работают на V8, также создали собственную виртуальную машину (по сей день один из самых быстрых динамических движков языка OO, когда-либо созданных), Animorphic Smalltalk VM (по сей день один из самых быстрых двигателей исполнения Smalltalk, когда-либо созданных), HotSpot JVM (самый быстрый JVM, когда-либо созданный, возможно, самый быстрый период VM) и OOVM (одна из самых эффективных виртуальных виртуальных машин Smalltalk).
Фактически, Ларс Бак, ведущий разработчик V8, работал над каждым из них, плюс несколько других.
Намного больше стимулов для оптимизации JavaScript-интерпретаторов, поэтому мы видим, что в Mozilla, Google и Microsoft вкладывается столько ресурсов. JavaScript должен быть загружен, проанализирован, скомпилирован и запущен в режиме реального времени, в то время как человек (обычно нетерпеливый) ждет его, он должен запускать WHILE, когда человек взаимодействует с ним, и делает это в неконтролируемом клиенте окружающей среды, которая может быть компьютером, телефоном или тостером. Он должен быть эффективным, чтобы эффективно работать в этих условиях.
Python и Ruby запускаются в среде, контролируемой разработчиком/развертывателем. Мягкий сервер или настольная система, в общем, где ограничивающим фактором будут такие вещи, как память или дисковый ввод-вывод, а не время выполнения. Или, где могут использоваться немоторные оптимизации, такие как кеширование. Для этих языков, вероятно, имеет смысл сосредоточиться на языковых и библиотечных функциях, установленных для оптимизации скорости.
Преимущество этого заключается в том, что у нас есть два больших высокопроизводительных JavaScript с открытым исходным кодом, которые могут и повторно используются для всех приложений, таких как Node.js.
Хорошая его часть связана с сообществом. Python и Ruby по большей части не имеют корпоративной поддержки. Никто не получает зарплату за работу на Python и Ruby полный рабочий день (и им особенно не платят за работу на CPython или MRI все время). V8, с другой стороны, поддерживается самой мощной ИТ-компанией в мире.
Кроме того, V8 может быть быстрее, потому что единственное, что важно для людей V8, - это интерпретатор - у них нет стандартной библиотеки для работы, нет проблем с дизайном языка. Они просто пишут переводчика. Что это.
Это не имеет ничего общего с законом об интеллектуальной собственности. Также Python не был разработан разработчиками Google (его создатель работает там вместе с несколькими другими коммиттерами, но им не платят за работу на 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, unladen-swallow, чтобы создать более быстрый интерпретатор Python, совместимый со стандартом переводчик. PyPy - еще один проект, который намеревается создать более быстрый Python. Существует также Psyco, предшественник PyPy, который может обеспечить повышение производительности для многих скриптов Python без изменения всего интерпретатора, и Cython, что позволяет писать высокопроизводительные библиотеки C для Python, используя что-то очень похожее на синтаксис Python.
Вводящий в заблуждение вопрос. V8 - это JIT (как раз вовремя компилятор) реализация JavaScript и в своей самой популярной не-браузерной реализации Node.js она построена вокруг цикла событий. CPython не является JIT и не является событием. Но они существуют в Python чаще всего в проекте PyPy - CPITON 2.7 (и скоро будет 3.0+) совместимый JIT. И, например, множество загружаемых серверных библиотек, таких как Tornado. Существуют тесты реального мира между PyPy, работающими с Tornado vs Node.js, а различия в производительности незначительны.
Я просто столкнулся с этим вопросом, и есть также большая техническая причина разницы в производительности, о которой не упоминалось. Python имеет очень большую экосистему мощных программных расширений, но большинство этих расширений написаны на C или других языках низкого уровня для производительности и сильно привязаны к API CPython.
Существует множество известных методов (JIT, современный сборщик мусора и т.д.), которые могут быть использованы для ускорения реализации CPython, но для этого потребуются существенные изменения API, что приведет к нарушению большинства расширений в этом процессе. CPython будет быстрее, но многое из того, что делает Python настолько привлекательным (обширный стек программного обеспечения), будет потеряно. Дело в том, что существует несколько более быстрых реализаций Python, но у них мало сцепления по сравнению с CPython.
Из-за различных приоритетов дизайна и целей использования, я считаю.
В общем, главная цель сценариев (динамические языки a.k.a.) - быть "клеем" между вызовами нативных функций. И эти нативные функции должны: a) охватывать наиболее важные/часто используемые области и b) быть максимально эффективными.
Вот пример: jQuery сортировка, приводящая к замораживанию Safari iOS Замораживание происходит из-за чрезмерного использования вызовов get-by-selector. Если get-by-selector будет реализован в собственном коде, и эффективно это будет не такая проблема вообще.
Рассмотрим демоверсию ray-tracer, которая часто используется для демонстрации V8. В Python-мире он может быть реализован в собственном коде, поскольку Python предоставляет все возможности для собственных расширений. Но в V8-сфере (клиентская песочница) у вас нет других опций, а не для того, чтобы сделать VM более эффективной. Таким образом, единственный вариант - реализация ray-tracer - с помощью кода script.
Так разные приоритеты и мотивации.
В Sciter Я сделал тест, реализовав довольно много полного ядра jQurey. На практических задачах, таких как ScIDE (IDE из HTML/CSS/ Script) Я считаю, что такое решение работает значительно лучше, чем любая оптимизация VM.
Как отмечали другие люди, Python имеет исполняемый JIT-компилятор в виде PyPy.
Создание значимых тестов всегда тонкое, но у меня есть простой тест K-means, написанный на разных языках - вы можете найти его . Одно из ограничений заключалось в том, что различные языки должны реализовывать один и тот же алгоритм и должны стремиться быть простыми и идиоматическими (в отличие от оптимизированных для скорости). Я написал все реализации, поэтому я знаю, что я не обманул, хотя я не могу претендовать на все языки, что то, что я написал, является идиоматическим (у меня есть только знание некоторых из них).
Я не претендую на какой-либо окончательный вывод, но PyPy был среди самых быстрых реализаций, которые я получил, намного лучше, чем Node. CPython, напротив, находился на самом медленном конце рейтинга.
Как и V8 - это просто реализация для JS, CPython - это всего лишь одна реализация для Python. Pypy имеет характеристики, соответствующие V8.
Кроме того, существует проблема воспринимаемой производительности: поскольку V8 изначально не блокируется, веб-разработчик приводит к более эффективным проектам, потому что вы сохраняете ожидания ввода-вывода. И V8 в основном используется для dev Web, где IO является ключевым, поэтому они сравнивают его с аналогичными проектами. Но вы можете использовать Python во многих и многих других областях, кроме веб-разработчиков. И вы даже можете использовать C-расширения для множества задач, таких как научные вычисления или шифрование, и хруст данных с пылающими функциями.
Но в Интернете большинство популярных проектов Python и Ruby блокируются. Python, в частности, имеет наследие синхронного стандарта WSGI, и на нем основаны фреймворки, такие как знаменитый Django.
Вы можете написать асинхронный Python (например, с Twisted, Tornado, gevent или asyncio) или Ruby. Но это не часто. Лучшие инструменты по-прежнему блокируются.
Однако, это некоторые причины того, почему реализации по умолчанию в Ruby и Python не так быстро, как V8.
Как отметил Йорг W Миттаг, ребята, работающие над V8, являются гениями VM. Python - это девчонка из страстных людей, очень хороша во многих доменах, но не специализируется на настройке VM.
У фонда Python Software очень мало денег: менее 40 тыс. в год для инвестиций в Python. Это выглядит безумным, когда вы думаете, что крупные игроки, такие как Google, Facebook или Apple, все используют Python, но это уродливая правда: большая часть работы выполняется бесплатно. Язык, который использует Youtube и существовал до Java, был изготовлен добровольцами.
Они умные и преданные добровольцам, но когда они идентифицируют, им нужно больше сока в поле, они не могут попросить 300 тыс. нанять специалиста по первоклассным специалистам в этой области знаний. Они должны искать кого-то, кто сделает это бесплатно.
Пока это работает, это означает, что вы должны быть очень осторожны в своих приоритетах. Следовательно, теперь нам нужно посмотреть:
Даже с новейшими современными функциями писать Javascript ужасно. У вас есть проблемы с определением области охвата, очень мало коллекций, ужасные манипуляции с строками и массивами, почти без stdlist, кроме даты, математики и регулярных выражений, и никакого синтаксического сахара даже для очень распространенных операций.
Но в V8 у вас есть скорость.
Это связано с тем, что скорость была главной целью для Google, поскольку это узкое место для рендеринга страниц в Chrome.
В Python главная цель - удобство использования. Потому что это почти никогда не было узким местом в проекте. Недостаточный ресурс здесь - время разработчика. Он оптимизирован для разработчика.
Поскольку реализация JavaScript не нуждается в обратной совместимости их привязок.
До недавнего времени единственными пользователями реализации JavaScript были веб-браузеры. Из-за требований безопасности только поставщики веб-браузеров имели право расширять функциональность, записывая привязки к времени выполнения. Таким образом, не было необходимости поддерживать совместимость API-интерфейса C API, было разрешено запрашивать, чтобы разработчики веб-браузера обновляли свой исходный код в процессе разработки JavaScript; они все время работали вместе. Даже V8, который был опоздавшим к игре, а также возглавил очень опытный разработчик, изменил API по мере его улучшения.
OTOH Ruby используется (главным образом) на стороне сервера. Многие популярные рубиновые расширения написаны как C-привязки (рассмотрим драйвер RDBMS). Другими словами, Ruby никогда не преуспел, не поддерживая совместимость.
Сегодня разница до сих пор существует. Разработчики, использующие node.js, жалуются на то, что трудно поддерживать совместимость своих родных расширений, так как V8 меняет API со временем (и это одна из причин, по которой w630 > .js был разветвлен). В этом отношении рубин IIRC по-прежнему придерживается гораздо более консервативного подхода.
V8 быстро связан с JIT, коленчатым валом, типом inferencer и оптимизированным по данным кодом. Tagged указатели, NaN-метки двойников. И, конечно же, он делает обычную оптимизацию компилятора посередине.
Простой механизм ruby, python и perl не выполняет ни одну из них, просто незначительные основные оптимизации.
Единственным крупным vm, который близок, является luajit, который даже не делает вывод типа, постоянную фальцовку, маркировку NaN или целые числа, но использует аналогичные небольшие структуры кода и данных, а не такие жирные, как плохие языки. И мои прототипы динамических языков, зелья и p2 имеют схожие функции, такие как luajit, и превосходят v8. При использовании дополнительной системы типа "постепенное типирование" вы можете легко превзойти v8, так как вы можете обойти коленчатый вал. См. Дротик.
Известные оптимизированные серверы, такие как pypy или jruby, по-прежнему страдают от различных сверхтехнических методов.
