PyPy — Как это может возможно разбить CPython?
PyPy является переопределением Python в Python, с помощью усовершенствованных методов, чтобы попытаться достигнуть лучшей производительности, чем CPython. Много лет тяжелой работы наконец окупились. Наши результаты скорости часто бьют CPython, в пределах от того, чтобы быть немного медленнее, к ускорениям до 2x на реальном коде приложения, к ускорениям до 10x на маленьких сравнительных тестах.
Как это возможно? Какая реализация Python использовалась для реализации PyPy? CPython? И каковы возможности PyPyPy или PyPyPyPy, побеждающего их счет?
(На связанной ноте..., почему кто-либо попробовал бы что-то вроде этого?)
2 ответа
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
Мы стремимся предоставить:
общую платформу перевода и поддержки для создания
{{1} } реализации динамических языков, подчеркивая четкое
разделение между спецификацией языка и аспектами реализации
. Мы называем этонабором инструментов RPython_.совместимая, гибкая и быстрая реализация языка Python _ , использующая вышеуказанный набор инструментов для включения новых расширенных высокоуровневых функций без необходимости кодирования низкоуровневых Детали.
Разделяя таким образом задачи, наша реализация Python - и других динамических языков - может автоматически генерировать своевременный компилятор для любого динамического языка. Это также позволяет использовать подход к решениям по реализации, включая многие , которые исторически находились вне контроля пользователя, такие как целевая платформа, память и модели потоковой передачи. , стратегии сборки мусора и применяемые оптимизации, в том числе необходимость наличия JIT в первую очередь.
Компилятор C gcc реализован на C, компилятор Haskell GHC написан на Haskell. Есть ли у вас какие-либо причины, по которым интерпретатор / компилятор Python не должен быть написан на Python?
PyPy реализован в Python, но он реализует JIT-компилятор для генерации нативного кода на лету.
Причина реализации PyPy поверх Python, вероятно, заключается в том, что это просто очень производительный язык, тем более что компилятор JIT делает производительность основного языка несколько несущественной.