Почему я не должен использовать PyPy поверх CPython, если PyPy работает в 6,3 раза быстрее?

Я много слышал о проекте PyPy . Они утверждают, что это в 6,3 раза быстрее, чем интерпретатор CPython на их сайте .

Всякий раз, когда мы говорим о динамических языках, таких как Python, скорость является одной из главных проблем. Чтобы решить эту проблему, говорят, что PyPy работает в 6,3 раза быстрее.

Вторая проблема - это параллелизм, печально известный Global Lock Interpreter Lock (GIL). Для этого PyPy говорит, что может дать Python без GIL .

Если PyPy может решить эти серьезные проблемы, каковы его слабые стороны, которые мешают более широкому принятию? То есть, что мешает кому-то, как я, типичному разработчику Python, перейти на PyPy прямо сейчас ?

ПРИМЕЧАНИЕ: PyPy более зрелый и лучше поддерживается, чем в 2013 году, когда был задан этот вопрос. Избегайте выводов из устаревшей информации.

1. PyPy, как быстро заметили другие, имеет слабую поддержку расширений Си . Он имеет поддержку, но, как правило, со скоростью, меньшей скорости Python, и в лучшем случае сомнительна. Следовательно, многие модули просто требуют CPython. PyPy не поддерживает numpy PyPy теперь поддерживает numpy . Некоторые расширения по-прежнему не поддерживаются (Pandas, SciPy и т. Д.), Прежде чем вносить изменения, посмотрите список поддерживаемых пакетов .
2. Поддержка Python 3 на данный момент является экспериментальной. только что достиг стабильного! По состоянию на 20 июня 2014 года, PyPy3 2.3.1 - Fulcrum вышла !
3. Иногда PyPy на самом деле не быстрее для «скриптов», для которых многие используют Python. Это краткосрочные программы, которые делают что-то простое и маленькое. Поскольку PyPy является JIT-компилятором, его основные преимущества заключаются в длительном времени выполнения и простых типах (таких как числа). Честно говоря, скорость до JIT в PyPy довольно плохая по сравнению с CPython.
4. Инерция . Переход на PyPy часто требует переоборудования, что для некоторых людей и организаций просто слишком много работы.

Это основные причины, которые влияют на меня, я бы сказал.

Этот сайт не утверждает, что PyPy работает в 6,3 раза быстрее, чем CPython. Цитировать:

Среднее геометрическое для всех тестов в 0,16 или 6,3 раза быстрее, чем CPython

Это заявление очень отличается от общего заявления, которое вы сделали, и когда вы поймете разницу, вы поймете, по крайней мере, одну причину, по которой вы не можете просто сказать «использовать PyPy». Может показаться, что я придирчив, но важно понять, почему эти два утверждения совершенно разные.

Чтобы сломать это:

• Заявление, которое они делают, относится только к тем эталонам, которые они использовали. Это абсолютно ничего не говорит о вашей программе (если ваша программа не совпадает с одним из их тестов).

• Утверждение о среднем по группе тестов. Нет никаких гарантий, что запуск PyPy даст улучшение в 6,3 раза даже для протестированных программ.

• Там нет никаких претензий , что PyPy даже запустить все программы , которые CPython работает вообще , не говоря уже быстрее.

Поскольку pypy не совместим на 100%, для его компиляции требуется 8 ГБ ОЗУ, это движущаяся цель, и она очень экспериментальная, где cpython стабилен, цель по умолчанию для сборщиков модулей в течение 2 десятилетий (включая расширения c, которые не работают на pypy ) и уже широко развернут.

Pypy, вероятно, никогда не будет эталонной реализацией, но это хороший инструмент для использования.

На второй вопрос легче ответить: вы в основном можете использовать PyPy в качестве замены, если весь ваш код - чистый Python. Однако многие широко используемые библиотеки (включая некоторые стандартные библиотеки) написаны на C и скомпилированы как расширения Python. Некоторые из них можно настроить для работы с PyPy, некоторые - нет. PyPy предоставляет тот же «обращенный вперед» инструмент, что и Python, т. Е. Python, но его внутренности разные, поэтому инструменты, взаимодействующие с этими внутренностями, работать не будут.

Что касается первого вопроса, я предполагаю, что это своего рода Catch-22 с первым: PyPy быстро развивается, пытаясь повысить скорость и улучшить совместимость с другим кодом. Это сделало его более экспериментальным, чем официальным.

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

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

Разработчики BDFL и CPython - удивительно умная группа людей, которым удалось помочь CPython отлично работать в таком сценарии. Вот бесстыдный плагин для блога: http://www.hydrogen18.com/blog/unpickling-buffers.html . Я использую Stackless, который является производным от CPython и сохраняет полный интерфейс модуля C. Я не нашел никакого преимущества в использовании PyPy в этом случае.

В: Если PyPy может решить эти сложные задачи (скорость, потребление памяти, параллелизм) по сравнению с CPython, каковы его слабые стороны, мешающие более широкому внедрению?

A: Во-первых, мало доказательств того, что команда PyPy может решить проблему скорости в целом . Многолетние свидетельства показывают, что PyPy запускает некоторые коды Python медленнее, чем CPython, и этот недостаток, похоже, очень глубоко укоренен в PyPy.

Во-вторых, текущая версия PyPy потребляет намного больше памяти, чем CPython в довольно большом количестве случаев. Так что PyPy еще не решил проблему потребления памяти.

Если PyPy решает упомянутые большие проблемы и в целом будет быстрее, меньше память голодная, и более дружественной к параллельности , чем CPython является открытым вопросом , который не может быть решен в краткосрочной перспективе. Некоторые люди держат пари, что PyPy никогда не сможет предложить общее решение, позволяющее ему доминировать над CPython 2.7 и 3.3 во всех случаях.

Если PyPy окажется лучше, чем CPython в целом, что сомнительно, то основным недостатком, влияющим на его более широкое применение, будет его совместимость с CPython. Также существуют проблемы, такие как тот факт, что CPython работает на более широком диапазоне процессоров и операционных систем, но эти проблемы гораздо менее важны по сравнению с целями PyPy по производительности и совместимости с CPython.

В: Почему я не могу сделать замену CPython на PyPy сейчас?

A: PyPy не на 100% совместим с CPython, потому что он не имитирует CPython. Некоторые программы могут по-прежнему зависеть от уникальных возможностей CPython, которые отсутствуют в PyPy, таких как привязки C, реализации C объектов и методов Python или инкрементный характер сборщика мусора CPython.

CPython имеет подсчет ссылок и сборщик мусора, PyPy имеет только сборку мусора.

Таким образом, объекты, как правило, удаляются раньше и __del__вызываются более предсказуемым способом в CPython. Некоторые программы полагаются на такое поведение, поэтому они не готовы к переходу на PyPy.

Некоторые другие программы работают с обоими, но используют меньше памяти с CPython, потому что неиспользуемые объекты освобождаются ранее. (У меня нет никаких измерений, чтобы указать, насколько это важно и какие другие детали реализации влияют на использование памяти.)

Для многих проектов разница между питонами с точки зрения скорости составляет 0%. Это те, в которых доминирует время разработки и где все питоны имеют одинаковое количество библиотечной поддержки.

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

Я нашел примеры, где PyPy медленнее, чем Python. Но: только на Windows.

C:\Users\User>python -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 294 msec per loop

C:\Users\User>pypy -m timeit -n10 -s"from sympy import isprime" "isprime(2**521-1);isprime(2**1279-1)"
10 loops, best of 3: 1.33 sec per loop

Итак, если вы думаете о PyPy, забудьте о Windows. В Linux вы можете добиться потрясающего ускорения. Пример (перечислите все простые числа от 1 до 1 000 000):

from sympy import sieve
primes = list(sieve.primerange(1, 10**6))

Это работает в 10 (!) Раз быстрее на PyPy, чем на Python. Но не на окнах. Там это только в 3 раза быстрее.

PyPy уже некоторое время поддерживает Python 3, но, согласно сообщению Энтони Шоу от 2 апреля 2018 года в HackerNoon, PyPy3 все еще в несколько раз медленнее PyPy (Python 2).

Для многих научных вычислений, в частности, для матричных вычислений, лучше выбрать numpy (см. FAQ: стоит ли устанавливать numpy или numpypy? ).

Pypy не поддерживает gmpy2. Вместо этого вы можете использовать gmpy_cffi, хотя я не проверял его скорость, и у проекта был один выпуск в 2014 году.

Что касается задач Project Euler, я часто использую PyPy, а для простых численных расчетов часто from __future__ import divisionдостаточно для моих целей, но поддержка Python 3 все еще работает с 2018 года, и ваша лучшая ставка на 64-битный Linux. Windows PyPy3.5 v6.0, последняя по состоянию на декабрь 2018 года, находится в стадии бета-тестирования.

Поддерживаемые версии Python

Чтобы процитировать дзен Python :

Читаемость имеет значение.

Например, Python 3.7 представил классы данных, а Python 3.8 представил fstring = .

В Python 3.7 и Python 3.8 могут быть другие функции, которые более важны для вас. Дело в том, что PyPy на данный момент не поддерживает Python 3.7 или Python 3.8.