PyPy - Как это может победить CPython? - PullRequest
256 голосов
/ 07 апреля 2010

Из блога открытого исходного кода Google :

PyPy - это переопределение Python в Python, использующее продвинутые методы для достижения лучшей производительности, чем CPython.Много лет тяжелой работы наконец окупились.Наши результаты по скорости часто превосходят CPython, начиная от чуть медленнее, до ускорений в 2 раза в реальном коде приложения и до 10 раз в небольших тестах.

Как это возможно?Какая реализация Python использовалась для реализации PyPy? CPython ?И каковы шансы того, что PyPyPy или PyPyPyPy превзойдут свои результаты?

(С другой стороны ... зачем кому-то пытаться что-то подобное?)

Ответы [ 4 ]

284 голосов
/ 10 января 2012

«PyPy - это повторная реализация Python в Python» - довольно вводящий в заблуждение способ описать PyPy, ИМХО, хотя это технически верно.

Есть две основные части PyPy.

  1. Структура перевода
  2. Интерпретатор

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

RPython является подмножеством нормального Python;весь код RPython - это код Python, но не наоборот.Формального определения RPython не существует, потому что RPython - это просто «подмножество Python, которое можно перевести с помощью среды перевода PyPy».Но для перевода код RPython должен быть статически типизирован (типы выводятся, вы не объявляете их, но это все равно строго один тип для каждой переменной), и вы не можете ничего делатькак и объявление / изменение функций / классов во время выполнения.

В этом случае интерпретатор является обычным интерпретатором Python, написанным на RPython.

Поскольку код RPython - это обычный код Python, его можно запустить на любом Pythonпереводчик.Но ни одно из заявлений PyPy о скорости не исходит из того, что он работает таким образом;это просто для быстрого цикла тестирования, потому что перевод интерпретатора занимает долго времени.

С этим пониманием должно быть сразу очевидно, что спекуляции о PyPyPy или PyPyPyPy на самом деле не вызываютлюбое чувство.У вас есть переводчик, написанный на RPython.Вы переводите его в код C, который быстро выполняет Python.Там процесс останавливается;нет больше RPython, чтобы ускорить его повторную обработку.

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


действительно инновационный аспект проекта PyPy заключается в том, что они не пишут сложные схемы GC или JIT-компиляторы вручную.Они пишут интерпретатор относительно просто в RPython, и для всех RPython является более низким уровнем, чем Python, он по-прежнему является объектно-ориентированным языком сборки мусора, гораздо более высоким уровнем, чем C. Затем инфраструктура перевода автоматически добавляет такие вещи, как GCи JIT.Таким образом, среда перевода - это огромное усилие, но она в равной степени применима и к интерпретатору Python Python, однако они меняют свою реализацию, предоставляя гораздо большую свободу в экспериментах для повышения производительности (не беспокоясь о появлении ошибок GC или обновлении).JIT-компилятор, чтобы справиться с изменениями).Это также означает, что когда они приступят к реализации интерпретатора Python3, он автоматически получит те же преимущества.И любые другие интерпретаторы, написанные с помощью платформы PyPy (которых на разных этапах полировки много).И все интерпретаторы, использующие инфраструктуру PyPy, автоматически поддерживают все платформы, поддерживаемые платформой.

Таким образом, истинное преимущество проекта PyPy состоит в том, чтобы отделить (насколько это возможно) все части реализации эффективной независимой от платформы платформы.переводчик для динамического языка.А затем придумайте одну хорошую реализацию их в одном месте, которую можно будет повторно использовать во многих переводчиках.Это не мгновенная победа, как «моя Python-программа работает быстрее сейчас», но это большая перспектива на будущее.

И она может запустить вашу Python-программу быстрее (возможно).

152 голосов
/ 07 апреля 2010

Q1. Как это возможно?

Ручное управление памятью (что делает CPython со своим счетом) может быть медленнее, чем автоматическое управление в некоторых случаях.

Ограничения в реализации интерпретатора CPython исключают некоторые оптимизации, которые может выполнять PyPy (например, мелкозернистые блокировки).

Как говорил Марсело, JIT. Возможность на лету подтвердить тип объекта может избавить вас от необходимости многократного разыменования указателя, чтобы в итоге получить метод, который вы хотите вызвать.

Q2. Какая реализация Python использовалась для реализации PyPy?

Интерпретатор PyPy реализован в RPython, который является статически типизированным подмножеством Python (язык, а не интерпретатор CPython). - Подробнее см. https://pypy.readthedocs.org/en/latest/architecture.html.

Q3. И каковы шансы того, что PyPyPy или PyPyPyPy выиграют у них?

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

Обновление: Недавно, на тщательно обработанном примере , PyPy превзошел аналогичную C-программу, скомпилированную с gcc -O3. Это надуманный случай, но он демонстрирует некоторые идеи.

Q4. Зачем кому-то пытаться что-то подобное?

с официального сайта. https://pypy.readthedocs.org/en/latest/architecture.html#mission-statement

Мы стремимся предоставить:

  • общая структура перевода и поддержки для создания
    реализации динамических языков, подчеркивая чистоту
    разделение между спецификацией языка и реализацией
    аспекты. Мы называем это RPython toolchain _.

  • совместимая, гибкая и быстрая реализация Python_ Язык, который использует вышеупомянутый набор инструментов для включения новых расширенных возможностей. функции высокого уровня без необходимости кодирования низкого уровня подробности.

Разделив проблемы таким образом, наша реализация Python - и другие динамические языки - способен автоматически генерировать Компилятор Just-in-Time для любого динамического языка. Это также позволяет смешанный подход к принятию решений, в том числе многие которые исторически находились вне контроля пользователя, такие как целевая платформа, модели памяти и потоков, сборка мусора применяемые стратегии и оптимизации, в том числе Во-первых, у тебя JIT.

Компилятор C gcc реализован на C, компилятор Haskell GHC написан на Haskell. У вас есть причина, по которой интерпретатор / компилятор Python не будет написан на Python?

23 голосов
/ 07 апреля 2010

PyPy реализован в Python, но он реализует JIT-компилятор для генерации нативного кода на лету.

Причиной реализации PyPy поверх Python, вероятно, является то, что это просто очень производительный язык, особеннопоскольку JIT-компилятор делает производительность основного языка несколько нерелевантной.

11 голосов
/ 19 ноября 2010

PyPy написан на Restricted Python.Насколько я знаю, он не работает поверх интерпретатора CPython.Ограниченный Python является подмножеством языка Python.AFAIK, интерпретатор PyPy скомпилирован в машинный код, поэтому при установке он не использует интерпретатор python во время выполнения.

Ваш вопрос, вероятно, предполагает, что интерпретатор PyPy выполняется поверх CPython во время выполнения кода. Редактировать: Да, чтобы использовать PyPy, вы сначала переводите Python-код PyPy, либо в C, и собираете его с помощью gcc, в байтовый код jvm или в код .NET CLI.См. Начало работы

...