PyPy - Как он может победить CPython?

Ответ 1

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?

Ответ 2

"PyPy - это повторная реализация Python в Python" - довольно вводящий в заблуждение способ описать PyPy, IMHO, хотя это технически верно.

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

• Структура перевода
• Интерпретатор

Структура перевода - это компилятор. Он компилирует 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. Таким образом, каркас перевода - это огромные усилия, но он одинаково хорошо применим и к интерпретатору PyPy python, но они меняют свою реализацию, что позволяет значительно увеличить свободу экспериментов для повышения производительности (не беспокоясь о том, чтобы вводить GC-ошибки или обновлять компилятор JIT, чтобы справиться с перемены). Это также означает, что когда они общаются с внедрением интерпретатора Python3, он автоматически получит те же преимущества. И любые другие интерпретаторы, написанные с фреймворком PyPy (из которых есть число на разных этапах полировки). И все интерпретаторы, использующие фреймворк PyPy, автоматически поддерживают все платформы, поддерживаемые каркасом.

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

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

Ответ 3

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

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

Ответ 4

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

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