Чому я не повинен використовувати PyPy над CPython, якщо PyPy в 6,3 рази швидший?

Я багато чув про проект PyPy . Вони стверджують, що це в 6,3 рази швидше, ніж інтерпретатор CPython на їхньому сайті .

Щоразу, коли ми говоримо про динамічні мови, як-от Python, швидкість - це одна з головних проблем. Щоб вирішити це, вони кажуть, що PyPy у 6,3 рази швидший.

Друге питання - паралелізм, сумнозвісний замок глобальних перекладачів (GIL). З цього приводу PyPy каже, що він може давати Python без GIL .

Якщо PyPy може вирішити ці великі виклики, то які її слабкі сторони перешкоджають більш широкому впровадженню? Тобто, що заважає комусь, як я, типовому розробнику Python, перейти на PyPy зараз ?

ПРИМІТКА: PyPy є більш зрілим і краще підтримується зараз, ніж це було у 2013 році, коли це питання було задано. Уникайте робити висновки із застарілої інформації.

1. PyPy, як і інші поспішили відзначити, має слабку підтримку розширень C . Він має підтримку, але, як правило, з меншою швидкістю, ніж на 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. Однак багато широко використовувані бібліотеки (включаючи частину стандартної бібліотеки) написані на С та складені як розширення 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 і зберігає повний інтерфейс модуля С. Я не знайшов жодної переваги щодо використання PyPy у такому випадку.

Питання: Якщо PyPy може вирішити ці великі проблеми (швидкість, споживання пам’яті, паралелізм) порівняно з CPython, то які його слабкі сторони заважають більш широкому впровадженню?

Відповідь: По-перше, мало свідчень того, що команда PyPy в цілому може вирішити проблему швидкості . Багаторічні дані свідчать про те, що PyPy виконує певні коди Python повільніше, ніж CPython, і цей недолік, схоже, закорінений дуже глибоко в PyPy.

По-друге, поточна версія PyPy споживає набагато більше пам’яті, ніж CPython у досить великому наборі випадків. Тож PyPy ще не вирішив проблеми споживання пам'яті.

Чи вирішує PyPy згадані великі виклики і чи буде взагалі швидше, менше голодної пам’яті та більш прихильним до паралелізму, ніж CPython, - це відкрите питання, яке не може бути вирішено за короткий термін. Деякі люди роблять ставку, що PyPy ніколи не зможе запропонувати генерала рішення, що дозволяє йому домінувати у CPython 2.7 та 3.3 у всіх випадках.

Якщо PyPy вдасться бути кращим за CPython в цілому, що сумнівно, головною слабкістю, що впливає на його більш широке прийняття, буде його сумісність із CPython. Існують також такі питання, як те, що CPython працює на більш широкому діапазоні процесорів і ОС, але ці питання є набагато менш важливими порівняно з цілями продуктивності PyPy та сумісністю з CPython.

Питання: Чому я не можу зараз відмовитися від заміни CPython на PyPy?

Відповідь: 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, але згідно з цим повідомленням HackerNoon від Ентоні Шоу від 2 квітня 2018 року , 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.