The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Выпуск Pyston 0.4, реализации языка Python с JIT-компилятором

04.11.2015 10:26

Представлен четвёртый выпуск проекта Pyston, в рамках которого компанией Dropbox, в которой работает Гвидо ван Россум, развивается высокопроизводительная реализация языка Python, созданная с использованием наработок проекта LLVM. Реализация примечательна применением современных технологий JIT-компиляции и нацелена на достижение высокой производительности, близкой к производительности традиционных системных языков, таких как C++. Код Pyston написан на языке C++ и распространяется под лицензией Apache.

В отличие от проекта PyPy, также продвигающего идею применения 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 и т.д.
  • Значительный прогресс в оптимизации производительности. В текущем виде Pyston на 25% быстрее CPython и на 25% медленнее PyPy 4.0. Напомним, что в прошлом выпуске выигрыш составлял около 1% и разработка находилась в состоянии неоптимизированного прототипа. Из улучшений отмечается создание собственной системы "размотки" исключений (C++ exception unwinder); реализация промежуточного JIT, размещённого между интерпретатором и LLVM JIT; новая система дискового кэширования результатов работы LLVM JIT; многочисленные улучшения методов трассировки исполнения кода; новая прослойка для трансляции вызовов C API и т.п.
  • Осуществлён переход с системы сборки на основе Makefile к применению CMake;
  • Расширена документация, в том числе подготовлены описания внутренней архитектуры.


  1. Главная ссылка к новости (http://blog.pyston.org/2015/11...)
  2. OpenNews: Выпуск PyPy 4.0, реализации Python, написанной на языке Python
  3. OpenNews: Увидел свет язык программирования Python 3.5.0
  4. OpenNews: Выпуск Jython 2.7, реализации языка Python на Java
  5. OpenNews: Выпуск Nuitka 0.5.9, компилятора для языка Python
  6. OpenNews: Представлен HOPE, JIT-компилятор для языка Python, транслирующий в C++
Лицензия: CC-BY
Тип: Программы
Ключевые слова: pyston, python
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (33) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.2, Аноним (-), 11:24, 04/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    >представлена... реализация... не будет GIL.

    По крайне мере хорошо, что эти релизации идут независимо и... не блокируют друг друга)

     
  • 1.5, Аноним (-), 12:05, 04/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +17 +/
    >высокой производительности, близкой к производительности традиционных системных языков, таких как C++.

    По горло уже сыт этим враньём, "близкого" там и в помине нет и быть не может.

     
     
  • 2.6, A.Stahl (ok), 12:15, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +10 +/
    Если вы произнесёте достаточно большую ложь и будете её повторять, то люди в итоге в неё поверят.
     
     
  • 3.15, Аноним (-), 14:30, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Сколько можно повторять эту банальщину?
     
     
  • 4.17, Красные Глаза (ok), 15:11, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Если вы произнесёте достаточно большую ложь и будете её повторять, то люди в итоге в неё поверят.
     
     
  • 5.18, Аноним (-), 15:53, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Совершенно справедливая симметричность.
     
     
  • 6.20, Аноним (-), 15:56, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    > Совершенно справедливая симметричность.

    Ой, промахнулся.

     
  • 3.19, Аноним (-), 15:56, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Если вы произнесёте достаточно большую правду и будете её повторять, то люди в итоге в неё поверят.
     
  • 2.16, Нимано (?), 14:59, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > По горло уже сыт этим враньём, "близкого" там и в помине нет
    > и быть не может.

    Читайте внимательнее!

    > нацелена на достижение высокой производительности, близкой к производительности традиционных системных языков, таких как C++
    > нацелена на достижение

    Т.е. похвальное стремление к светлому будущему!
    Ну а то, что "не шмогла я, не шмогла!", это уже издержки нашей реальности ...

     
     
  • 3.27, all_glory_to_the_hypnotoad (ok), 17:00, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    так и это враньё, питон даже обмазанный JITами не будет иметь такой производительности.
     
     
  • 4.30, Нимано (?), 18:09, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > питон даже обмазанный JITами не будет иметь такой
    > производительности.

    Да легко! Делов-то:  
    с помощью либастрала забабахать нормальное предсказание типов и освобождение памяти (т.е. убрать подсчет ссылок/ГЦ) и запилить 100% unboxing при компиляции.

    Ну или тихой сапой протолкнуть некоторые вещи в плюсовой стандарт.

    А еще: вполне может быть, что прилетят инопланетяне и подарят схему спец-ЦПУ, который будет работать исключительно на питоне.


     
  • 4.51, freehck (ok), 12:50, 05/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Нет, ну почему же. Очень даже может. Это ж не виртуальная машина,  как скажем JVM, где такой же производительности быть точно не может. Если они используют JIT именно что для компиляции в нативный код -- то высокая производительность в принципе сможет быть достигнута.

    Вот если бы Вы то же самое сказали по поводу JVM, это было бы более справедливо. Впрочем, недавно мне матёрые явисты объяснили, что проблема тут в выдёргивании слов из контекста: Java действительно обеспечивает производительность компилируемых языков *за счёт хорошо спроектированного параллелизма выполнения*. То есть когда явисты говорят о том, что обгоняют компилируемые языки, надо отдавать себе отчёт, что сравниваются многопоточные java-приложения с не очень хорошо распараллеленными C-аналогами. И кстати недавняя новость о переписанной на сях Apache Cassandra явное тому подтверждение.

     
     
  • 5.52, userd (ok), 15:18, 05/11/2015 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Опыт, конечно, говорит - "никогда не говори никогда",
    но по поводу «Очень даже может» есть серьёзные сомнения.

    у 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*,
    но это довольно сложно.

     
  • 5.54, all_glory_to_the_hypnotoad (ok), 01:07, 06/11/2015 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Если они используют JIT именно что для компиляции в нативный код -- то высокая производительность в принципе сможет быть достигнута.

    Это сильно зависит от ЯП. Питон задизайнен внутри так, то такое в принципе невозможно. Да и у любых аналогичных по динамичности ЯП точно такие же проблемы (ruby, js и прочий крап). Убогий пых имеет значительно больший потенциал для оптимизаций чем всё это вместе взятое.

     
     
  • 6.55, Аноним (-), 15:04, 06/11/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ставка на оптимизацию в наш век сверхбыстрых камней и грошовой памяти явный моветон. Никому это сейчас не нужно....
     
  • 2.36, Аноним (-), 19:20, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    погугли polimorphic inline cache
     
     
  • 3.45, Нимано (?), 22:49, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > погугли polimorphic inline cache

    погуглите "static dispatch" и "dynamic dispatch" (заодно и  и подумайте на досуге, почему первое всегда будет быстрее второго. Особенно там, где "динамизм" используется вовсю (как например в батарейках питона).
    Я прокапитаню:
    Даже минимальная проверка типа с вызовом метода всегда будет медленнее вызова без проверки (информацию о типе нужно где-то хранить и извлекать. Все это может быть проделанно хоть и очень быстро, но отнюдь не мгновенно).
    А если еще учитывать такие штуки как векторизация/SIMD, "inlining классический", "branch prediction" железки и то, что сам CPU-кэш отнюдь не резиновый ...
    Так что, особенно при работе с большими массивами примитивных типов, если нет гарантий того, что тип всегда одинаков (а их, как ни странно, обычно таки нет – динамическая типизация-с) все будет может и не совсем (на порядок) уныло, но однозначно и заметно медленне.

     
  • 2.41, Аноним (-), 20:59, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • –2 +/
    почему у JavaScript близкая к C++ производительность получилась, а у python невозможна?
     
     
  • 3.43, all_glory_to_the_hypnotoad (ok), 22:03, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +2 +/
    не получилась.
     
     
  • 4.56, Аноним (-), 15:06, 06/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ню да, ню да... Конечно.  
     

  • 1.9, anonymous (??), 12:28, 04/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > В текущем виде Pyston на 25% быстрее CPython и на 25% PyPy 4.0

    С pypy.org

    > The geometric average of all benchmarks is 7.0 times faster than CPython

    Кто-то нагло звиздит.

     
     
  • 2.13, Никто (??), 14:21, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +5 +/
    Правильный выбор бенчмарков решает.
     

  • 1.12, Аноним (-), 14:02, 04/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Почему pyston_pgo на графике присутствует только в легенде?
     
     
  • 2.47, Ytch (ok), 02:45, 05/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Он воистину легендарный!
     
  • 2.58, wWolf (?), 12:51, 07/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Ну так написано же — less is better :)
     

  • 1.40, Аноним (-), 20:57, 04/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >В текущем виде Pyston на 25% быстрее CPython

    jit компилятор быстрее интерпретатора на четверть. Это круто!

     
  • 1.42, Я (??), 21:10, 04/11/2015 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Почему они пилят реализацию второй ветки, когда все кроме легаси уже несколько лет как перешли на третью?
     
     
  • 2.46, Alexey (??), 23:26, 04/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Наверное, потому что для их задач разница не принципиальна.
     
  • 2.49, xPhoenix (ok), 11:30, 05/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    К сожалению, не все. Есть одна фирма-лидер [сарказм], которая идёт к успеху и начинает новый проекты на Python с использованием Python 2.7 и Django 1.4.
     
  • 2.53, Аноним (-), 17:47, 05/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Потому тропбукс на двойке
     
  • 2.57, Аноним (-), 05:20, 07/11/2015 [^] [^^] [^^^] [ответить]  
  • +/
    Можно спросить у самого Гвидо...
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру