Представлен (http://blog.pyston.org/2015/11/03/102/) четвёртый выпуск проекта Pyston (http://www.pyston.org), в рамках которого компанией Dropbox, в которой работает Гвидо ван Россум, развивается высокопроизводительная реализация языка Python, созданная с использованием наработок проекта LLVM. Реализация примечательна применением современных технологий JIT-компиляции и нацелена на достижение высокой производительности, близкой к производительности традиционных системных языков, таких как C++. Код Pyston написан на языке C++ и распространяется (https://github.com/dropbox/pyston) под лицензией Apache.
В отличие от проекта PyPy (https://www.opennet.ru/opennews/art.shtml?num=43218), также продвигающего идею применения JIT для ускорения выполнения Python-скриптов, в Pyston используется не трассирующий JIT, базирующийся на компиляции в машинный код часто выполняемых циклов, а применяемый в современных JavaScript-движках JIT на основе трансляции отдельных методов (method-at-a-time), который, по мнению инженеров Dropbox, является более перспективной технологией. Принцип работы Pyston сводится к разбору кода на языке Python и его трансляции в промежуточное представление LLVM (IR, Intermediate Representation). Далее IR-представление проходит обработку в оптимизаторе LLVM и передаётся для исполнения в JIT-движок LLVM, который преобразует IR-представление в машинный код.Для получения информации о типах переменных для программ на динамическом языке Python применяется техника вероятностного предсказания типов объектов с последующим уточнением правильности выбора типа в процессе выполнения. Таким образом Pyston постоянно варьирует выполнение между двумя ветками - быстрой, когда данные о предсказанных типах подтверждаются, и медленной, используемой в случае рассогласования данных о типе. Работа может осуществляться в многопоточном режиме, допускающем параллельное выполнение нескольких нитей кода на языке Python и избавленном от глобальной блокировки интерпретатора (GIL, global interpreter lock).
Особенности нового выпуска:
- Проведена значительная работа по улучшению совместимости с CPython. Реализована поддержка практически всей семантики языка Python. Уровень поддержи Python доведён до возможности применения Pyston для запуска серверного ПО Dropbox, отвечающего за генерацию страниц. Обеспечена совместимость с большим числом стандартных библиотек, в том числе добавлена начальная поддержка NumPy. Успешно пройдено 153 дополнительной проверки из тестового набора CPython. Из новых возможностей отмечается поддержка Unicode, множественного наследования, weakrefs и финализаторов ("__del__"), выражений "exec s in {}", мутирующих функций, C API, многострочных выражений в REPL и т.д.- Значительный прогресс (http://speed.pyston.org/) в оптимизации производительности. В текущем виде Pyston на 25% быстрее CPython и на 25% медленнее PyPy 4.0. Напомним, что в прошлом выпуске выигрыш составлял около 1% и разработка находилась в состоянии неоптимизированного прототипа. Из улучшений отмечается создание собственной системы "размотки" исключений (C++ exception unwinder); реализация промежуточного JIT, размещённого между интерпретатором и LLVM JIT; новая система дискового кэширования результатов работы LLVM JIT; многочисленные улучшения методов трассировки исполнения кода; новая прослойка для трансляции вызовов C API и т.п.
<center><img src="https://www.opennet.ru/opennews/pics_base/0_1446624067.png&q... style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></center>
- Осуществлён переход с системы сборки на основе Makefile к применению CMake;
- Расширена документация (https://github.com/dropbox/pyston/wiki), в том числе подготовлены описания внутренней архитектуры.
URL: http://blog.pyston.org/2015/11/03/102/
Новость: https://www.opennet.ru/opennews/art.shtml?num=43257
>представлена... реализация... не будет GIL.По крайне мере хорошо, что эти релизации идут независимо и... не блокируют друг друга)
>высокой производительности, близкой к производительности традиционных системных языков, таких как C++.По горло уже сыт этим враньём, "близкого" там и в помине нет и быть не может.
Если вы произнесёте достаточно большую ложь и будете её повторять, то люди в итоге в неё поверят.
Сколько можно повторять эту банальщину?
Если вы произнесёте достаточно большую ложь и будете её повторять, то люди в итоге в неё поверят.
Совершенно справедливая симметричность.
> Совершенно справедливая симметричность.Ой, промахнулся.
Если вы произнесёте достаточно большую правду и будете её повторять, то люди в итоге в неё поверят.
> По горло уже сыт этим враньём, "близкого" там и в помине нет
> и быть не может.Читайте внимательнее!
> нацелена на достижение высокой производительности, близкой к производительности традиционных системных языков, таких как C++
> нацелена на достижениеТ.е. похвальное стремление к светлому будущему!
Ну а то, что "не шмогла я, не шмогла!", это уже издержки нашей реальности ...
так и это враньё, питон даже обмазанный JITами не будет иметь такой производительности.
> питон даже обмазанный JITами не будет иметь такой
> производительности.Да легко! Делов-то:
с помощью либастрала забабахать нормальное предсказание типов и освобождение памяти (т.е. убрать подсчет ссылок/ГЦ) и запилить 100% unboxing при компиляции.Ну или тихой сапой протолкнуть некоторые вещи в плюсовой стандарт.
А еще: вполне может быть, что прилетят инопланетяне и подарят схему спец-ЦПУ, который будет работать исключительно на питоне.
Нет, ну почему же. Очень даже может. Это ж не виртуальная машина, как скажем JVM, где такой же производительности быть точно не может. Если они используют JIT именно что для компиляции в нативный код -- то высокая производительность в принципе сможет быть достигнута.Вот если бы Вы то же самое сказали по поводу JVM, это было бы более справедливо. Впрочем, недавно мне матёрые явисты объяснили, что проблема тут в выдёргивании слов из контекста: Java действительно обеспечивает производительность компилируемых языков *за счёт хорошо спроектированного параллелизма выполнения*. То есть когда явисты говорят о том, что обгоняют компилируемые языки, надо отдавать себе отчёт, что сравниваются многопоточные java-приложения с не очень хорошо распараллеленными C-аналогами. И кстати недавняя новость о переписанной на сях Apache Cassandra явное тому подтверждение.
Опыт, конечно, говорит - "никогда не говори никогда",
но по поводу «Очень даже может» есть серьёзные сомнения.у Python (в реализации CPython) тоже виртуальная машина.
Для любой функции на python с помощью dis.dis можно получить код:
>>> import dis
>>> def ps(a,b): print a+b
>>> dis.dis(ps)3 0 LOAD_FAST 0 (a)
3 LOAD_FAST 1 (b)
6 BINARY_ADD
7 PRINT_ITEM
8 PRINT_NEWLINE
9 LOAD_CONST 0 (None)
12 RETURN_VALUE
Это стековая машина, манипулирующая данными в довольно абстрактной манере.
Всё - числа, строки, списки, экземпляры объектов и т.п. - всё представляется в виде PyObject* ( https://docs.python.org/2/c-api/intro.html, https://docs.python.org/2/c-api/structures.html )
и код виртуальной машины "не знает" что он складывает и печатает - числа, строки или объекты. Конечно, в какой-то момент времени интерпретатор выяснит что оба слагаемые - числа, вычислит и вернёт сумму, но по логике работы интерпретатора это должно произойти как можно позже.Я не очень внимателен к достижениям авторов jit и компиляторов (это я про Nuitka), но как мне показалось первые достижения связаны с разворачиванием цикла интерпретатора + генерацией кода в эпилоге функции + улучшение реализации циклов.
Предполагаемая высокая производительность требует разумного отказа от PyObject*,
но это довольно сложно.
> Если они используют JIT именно что для компиляции в нативный код -- то высокая производительность в принципе сможет быть достигнута.Это сильно зависит от ЯП. Питон задизайнен внутри так, то такое в принципе невозможно. Да и у любых аналогичных по динамичности ЯП точно такие же проблемы (ruby, js и прочий крап). Убогий пых имеет значительно больший потенциал для оптимизаций чем всё это вместе взятое.
Ставка на оптимизацию в наш век сверхбыстрых камней и грошовой памяти явный моветон. Никому это сейчас не нужно....
погугли polimorphic inline cache
> погугли polimorphic inline cacheпогуглите "static dispatch" и "dynamic dispatch" (заодно и и подумайте на досуге, почему первое всегда будет быстрее второго. Особенно там, где "динамизм" используется вовсю (как например в батарейках питона).
Я прокапитаню:
Даже минимальная проверка типа с вызовом метода всегда будет медленнее вызова без проверки (информацию о типе нужно где-то хранить и извлекать. Все это может быть проделанно хоть и очень быстро, но отнюдь не мгновенно).
А если еще учитывать такие штуки как векторизация/SIMD, "inlining классический", "branch prediction" железки и то, что сам CPU-кэш отнюдь не резиновый ...
Так что, особенно при работе с большими массивами примитивных типов, если нет гарантий того, что тип всегда одинаков (а их, как ни странно, обычно таки нет – динамическая типизация-с) все будет может и не совсем (на порядок) уныло, но однозначно и заметно медленне.
почему у JavaScript близкая к C++ производительность получилась, а у python невозможна?
не получилась.
Ню да, ню да... Конечно.
> В текущем виде Pyston на 25% быстрее CPython и на 25% PyPy 4.0С pypy.org
> The geometric average of all benchmarks is 7.0 times faster than CPython
Кто-то нагло звиздит.
Правильный выбор бенчмарков решает.
Почему pyston_pgo на графике присутствует только в легенде?
Он воистину легендарный!
Ну так написано же — less is better :)
>В текущем виде Pyston на 25% быстрее CPythonjit компилятор быстрее интерпретатора на четверть. Это круто!
Почему они пилят реализацию второй ветки, когда все кроме легаси уже несколько лет как перешли на третью?
Наверное, потому что для их задач разница не принципиальна.
К сожалению, не все. Есть одна фирма-лидер [сарказм], которая идёт к успеху и начинает новый проекты на Python с использованием Python 2.7 и Django 1.4.
Потому тропбукс на двойке
Можно спросить у самого Гвидо...