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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Q: почему я не могу сделать падение в замене CPython на PyPy сейчас?

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

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

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

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

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

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

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

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

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

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 раза быстрее.