что такое pypy в питоне
PyPy3, полноценная замена классического Python3.
Цитата:
«Если необходимо, чтобы Ваш код работал быстрее,
то вероятно, следует просто использовать PyPy»
Гвидо ван Россум (создатель Python).
Общие сведения о PyPy.
Поддерживаются и обслуживаются следующие архитектуры ЦП:
Скорость исполнения кода компилятором PyPy.
Основной исполняемый файл pypy поставляется с компилятором Just-in-Time. Он действительно быстро запускает большинство тестов, включая очень большие и сложные приложения Python, а не только 10-строчные.
Два случая, когда PyPy не сможет ускорить код:
Таким образом, лучше всего PyPy работает при выполнении длительно выполняющихся программ, когда значительная часть времени тратится на выполнение кода Python. Это случай, охватываемый большинством проводимых тестов.
Установка PyPy3 на ОС Windows:
Установка PyPy3 ни чем не отличается от установки классического Python3. Загрузить исходники PyPy3 для ОС Windows можно с официальной страницы. Дистрибутив PyPy3 Windows 32 bit совместим с любыми 32- или 64-битными ОС Windows.
Так же, может понадобиться установщик библиотеки времени выполнения VC. Загрузить файл vcredist.x86.exe можно с официальной страницы https://www.pypy.org
Установка PyPy3 на Linux (ОС Ubuntu/Debian):
Команда разработчиков PyPy предоставляет предварительно скомпилированные двоичные файлы для многих платформ и ОС. Загрузить исходники PyPy3 можно с официальной страницы.
PyPy готов к запуску сразу после распаковки его из tarball или zip-архива, без необходимости устанавливать его в каком-либо конкретном месте:
Установка дополнительных модулей для PyPy3.
Для PyPy3, установленного в virtualenv все равно необходимо обновить pip и wheel до последних версий через:
Совместимость с классическим Python3.
PyPy3 поддерживает API CPython C, однако есть несовместимые конструкции. Команда разработчиков настоятельно рекомендует использовать CFFI, который уже встроен в дистрибутив PyPy3. Для работы небольшого количества библиотек потребуется немного усилий, но есть известные истории успеха.
Расширения языка C должны быть перекомпилированы для PyPy, чтобы они работали. В зависимости от вашей системы сборки это может работать из коробки или будет немного сложнее.
В основном PyPy3 поддерживает стандартные библиотечные модули. Обратите внимание, что многие модули python3 реализованы на чистом Python, следовательно они точно будут работать. Пожалуйста, просто проверьте, сможет ли PyPy3 на вашей системе импортировать следующие модули:
Если PyPy3 импортирует вышеуказанные модули без ошибок, то он полностью совместим с вашим Python3 и должен работать без каких либо ошибок.
Все сторонние модули, которые написаны на чистым python в CPython, конечно будут работать после успешной установки.
Различия, связанные со стратегиями сбора мусора.
Сборщики мусора, используемые или реализованные PyPy3, не основаны на подсчете ссылок, поэтому объекты не освобождаются мгновенно, когда они больше недоступны. Наиболее очевидный эффект от этого заключается в том, что файлы (и сокеты и т. д.) не закрываются сразу после выхода за пределы области видимости. Это отличие от классического Python3, не будет изменяться командой разработчиков.
Следующий код заполнит файл не сразу, а только через определенный промежуток времени, когда GC выполнит сборку мусора и очистит вывод:
Правильное использование заключается в следующем:
Точно так же помните, что необходимо закрывать неизрасходованный генератор, чтобы ожидающие завершения операторы finally или with выполнялись немедленно:
В более общем смысле, методы __del__() не выполняются так же предсказуемо, как на CPython: в PyPy3 они запускаются через некоторое время (или не запускаются вообще, если программа тем временем завершает работу).
Игнорируемые исключения.
Если это поведение явно не предусмотрено конструкцией и не задокументировано как таковое (например, для hasattr() ), в большинстве случаев PyPy будет поднимать исключения.
Идентичность встроенных типов ( is и id ).
Различия в производительности.
CPython имеет оптимизацию, которая может сделать повторную конкатенацию строк неквадратичной. Например, такой код выполняется за время O(n) :
В PyPy3 этот код всегда будет иметь квадратичную сложность. Также обратите внимание, что оптимизация CPython хрупкая и в любом случае может сломаться из-за небольших изменений в коде. Так что все равно необходимо заменить код выше на:
В принципе это основные отличия с которыми сталкивается 80% разработчиков.
PyPy: Ускоряем Python с минимальными усилиями
Содержание
Списки Python
Короче говоря, список-это набор произвольных объектов, несколько схожий с массивом во многих других языках программирования, но более гибкий. Списки определяются в Python путем заключения разделенной запятыми последовательности объектов в квадратные скобки ([]), как показано ниже:
Если нет, вы можете загрузить готовый двоичный файл для вашей операционной системы. После завершения загрузки просто распакуйте архив и можете не устанавливая использовать PyPy в любом месте:
Перед выполнением приведенного выше кода, вам необходимо находиться внутри папки, в которую вы загрузили двоичный файл. Обратитесь к документации по установке для полных инструкций.
PyPy в действии
Теперь у вас установлен PyPy, и вы готовы увидеть его в действии! Для этого создайте файл Python с именем script.py и поместите в него следующий код:
Скрипт из двух вложенных циклов for добавляет числа от 1 до 9999 и выводит результат.
Чтобы узнать, сколько времени потребуется для его выполнения, добавьте выделенные строки:
Попробуйте запустить его с помощью Python. Вот что я получаю на MacBook Pro 2015 года:
Теперь запустим сценарий с помощью PyPy:
Данный синтетический тест показал, что PyPy примерно в 94 раза быстрее Python!
Для более серьезных тестов вы можете взглянуть на PyPy Speed Center, где разработчики запускают ночные тесты с различными исполняемыми параметрами.
Нужно помнить, что производительность PyPy напрямую зависит от того, что делает ваш код. В некоторых ситуациях PyPy работает медленнее. Однако, в среднем, это в 4,3 раза быстрее, чем Python.
PyPy и его особенности
Исторически PyPy имел в виду две вещи:
Вы уже видели второе значение в действии, установив PyPy и запустив с ним небольшой скрипт. Реализация Python, которую вы использовали, была написана с использованием динамической языковой среды под названием RPython, точно так же, как CPython был написан на C, а Jython был написан на Java.
Вам не говорили, что PyPy написан на Python? Причина, по которой PyPy стал известен как интерпретатор Python, написанный на Python (а не на RPython), заключается в том, что RPython использует тот же синтаксис, что и Python.
Чтобы все прояснить, вот как создается PyPy:
Вам не нужно проходить все эти шаги, чтобы использовать PyPy, так как исполняемый файл уже доступен для установки.
Поскольку очень сложно использовать одно и то же слово для обозначения фреймворка и реализации, команда, стоящая за PyPy, решила отойти от этого двойного использования. Теперь PyPy относится только к реализации Python. Фреймворк называется набором инструментов перевода RPython.
Далее вы узнаете о функциях, которые в некоторых случаях делают PyPy лучше и быстрее, чем Python.
Just-In-Time (JIT) компилятор
Прежде, чем перейти к JIT-компиляции, рассмотрим свойства компилируемых и интерпретируемых языков программирования.
Компилируемые ЯП более производительны, но их сложно портировать на различные архитектуры и ОС. Интерпретируемые ЯП лучше портируются, но их производительность намного хуже.
Существуют языки, вроде Python, которые сочетают в себе оба свойства: исходный текст сначала компилируется в промежуточный байт-код, а потом интерпретируется CPython. Это позволяет софту работать стабильнее и сохраняет преимущество импорта.
Однако производительность по-прежнему далека от компилируемой версии, поскольку та способна выполнять множество невозможных для байт-кода оптимизаций. Здесь появляется JIT-компилятор, объединяющий лучшие части обоих миров. Рассмотрим шаги JIT-компиляции, необходимые для обеспечения производительности:
Если вспомнить два вложенных цикла из начала статьи, PyPy обнаружил, что одна и та же операция выполняется несколько раз, скомпилировал ее в машинный код, оптимизировал и поменял реализации местами. Вот почему мы увидели значительное увеличение производительности.
Сборщик мусора
Всякий раз, когда вы создаете любые объекты, под них выделяется память. Если неиспользуемые объекты не чистить, память закончится и произойдет сбой программы.
В C и C++ проблему обычно приходится решать вручную. Другие языки программирования, вроде Python и Java, делают это автоматически. Процесс называется автоматической сборкой мусора – существует несколько методов ее выполнения.
В CPython счетчик ссылок на объект увеличивается всякий раз, когда на него ссылаются и уменьшается при разыменовании. Когда счетчик равен нулю, CPython автоматически вызывает функцию освобождения памяти для объекта, но есть один нюанс. Когда количество ссылок большого дерева объектов становится равным нулю, все связанные объекты освобождаются. Возможна длинная пауза, во время которой программа простаивает. Есть также вариант, при котором подсчет ссылок не сработает. Рассмотрим следующий код:
В приведенном коде определяется новый класс, создается экземпляр, его свойству присваивается ссылка на себя, а экземпляр удаляется.
В этот момент экземпляр уже недоступен, однако подсчет ссылок не удаляет его из памяти, поскольку есть ссылка на себя, и счетчик не равен нулю. Такая ситуация называется циклом ссылок, и она не решается с помощью их подсчета.
В этом случае CPython использует другой инструмент – циклический сборщик мусора. Он пробегает по всем объектам в памяти, идентифицирует доступные и освобождает недостижимые, поскольку они больше не активны. Это исправляет проблему с циклом ссылок, однако могут появиться заметные паузы, когда в памяти находится большое количество объектов.
PyPy использует только второй метод. Он периодически ходит по «живым» объектам, начиная с корня. Это дает ему преимущество перед CPython, делая меньше затраченное на управление памятью время. Вместо того, чтобы делать все за один подход, PyPy разбивает работу на части. Такой подход добавляет всего несколько миллисекунд после каждой коллекции, а не сотни, как в CPython.
Сборка мусора является сложной задачей и содержит гораздо больше деталей, которые выходят за рамки данного материала. Более подробную информацию о ней можно найти в документации.
Ограничения PyPy
PyPy не всегда оказывается подходящим инструментом и может заставить приложение работать намного медленнее, чем CPython. Вот почему важно помнить о следующих ограничениях.
Некорректная работа с C-Extensions
Всякий раз, когда вы используете С-расширения, программа будет работать намного медленнее чем в CPython, т. к. они не поддерживаются полностью, и PyPy не может их оптимизировать. Также PyPy должен эмулировать подсчет ссылок для этой части кода, что делает его еще более медленным.
В таких случаях рекомендуется заменить расширение чистой версией Python, чтобы JIT мог его оптимизировать.
Разработчики трудятся над C-Extensions: некоторые пакеты уже импортированы на PyPy и работают так же быстро.
Работает только с Long-Running программами
Представьте, что вы хотите пойти в магазин, который находится очень близко от вашего дома. Вы можете идти пешком или на машине.
Ваша машина явно намного быстрее ваших ног. Однако подумайте, что вам потребуется сделать:
Вождение автомобиля связано с большими накладными расходами, и это не всегда того стоит, если место, куда вы хотите поехать, находится поблизости!
А теперь подумайте, что бы произошло, если бы вы захотели отправиться в соседний город в пятидесяти милях от вас. Конечно, стоило бы поехать туда, а не идти пешком.
Хотя разница в скорости не так заметна, как в приведенной выше аналогии и это утверждение также верно для PyPy и CPython.
Когда вы запускаете скрипт с PyPy, он делает много вещей, чтобы ваш код работал быстрее. Если сценарий слишком мал, то расходы приведут к тому, что ваш сценарий будет работать медленнее, чем в CPython. С другой стороны, если у вас есть длительно работающий сценарий, эти расходы могут принести значительные преимущества в производительности.
Чтобы убедиться в этом, запустите следующий небольшой скрипт как в CPython, так и в PyPy:
Есть небольшая задержка, когда вы запускаете его с помощью PyPy, в то время как в CPython старт происходит мгновенно. На MacBook Pro использование CPython займет 0.0004873276 секунды, а в случае с PyPy – 0.0019447803 секунды.
Не делает компиляцию заранее
PyPy не является полностью компилируемой реализацией Python. Из-за присущего Python динамизма, код невозможно скомпилировать в двоичный файл и повторно его использовать.
PyPy – это runtime-интерпретатор, который работает быстрее, чем полностью интерпретируемый язык, но медленнее, чем полностью компилируемый.
Заключение
PyPy – это быстрая и эффективная альтернатива CPython. Запустив свой скрипт с его помощью, вы можете получить значительное улучшение скорости, не внося ни одного изменения в код. У него есть ограничения, и вам нужно будет протестировать программу, чтобы проанализировать целесообразность использования альтернативного интерпретатора.
В этом уроке вы узнали:
Если вашему скрипту Python нужно немного увеличить скорость, попробуйте PyPy. В зависимости от сложности вашей программы, вы можете получить заметное улучшение скорости!
Почему существует так много Питонов?
Удивительно, но это довольно неоднозначное заявление. Что я имею ввиду под “Питоном”? Может, абстрактный интерфейс Питона? Или CPython, распространенная реализация Питона (не путать с похожим по названию Cython)? Или я имею ввиду что-то совсем иное? Может, я косвенно ссылаюсь на Jython, или IronPython, или PyPy. Или может я отвлекся так сильно, что говорю о RPython или RubyPython (которые очень сильно отличаются).
Не смотря на схожесть в названиях указанных выше технологий, некоторые из них имеют совсем другие задачи (или, как минимум, работают совершенно иными способами)
При работе с Питоном я столкнулся с кучей таких технологий. Инструменты *ython. Но лишь недавно я уделил время, чтобы разобраться, что они собой представляют, как они работают и почему они (каждая по-своему) необходимы.
В этом посте я начну с нуля и пройдусь по разным реализациям Питона, а закончу подробным введением в PyPy, за которым, по моему мнению, будущее языка.
Все начинается с понимания того, чем на самом деле является “Питон”.
Если у вас хорошее понимание машинного кода, виртуальных машин и так далее, можете пропустить этот раздел.
Питон интерпретируемый или компилируемый?
Это распространенный источник непонимания среди новичков Питона.
Первое, что необходимо понять: “Питон” – это интерфейс. Существует спецификация, описывающая, что должен делать Питон, и как он должен себя вести (что справедливо для любого интерфейса). И существует несколько имплементаций (что также справедливо для любого интерфейса).
Второе: “интерпретируемый” и “компилируемый” это свойства имплементации, но не интерфейса.
Так что сам вопрос не совсем корректен.
В случае с самой распространенной реализацией (CPython: написанный на C, часто называемый просто “Python”, и, конечно, именно тот, который вы используете, если понятия не имеете о чем я толкую) ответ: интерпретируемый, с некоторой компиляцией. CPython компилирует* исходный код на Питоне в байткод, а затем интерпретирует этот байткод, запуская его в процессе.
* Замечание: это не совсем “компиляция” в традиционном смысле. Обычно, мы считаем, что “компиляция” это конвертация из высокоуровневого языка в машинный код. Тем не менее – в некотором роде это “компиляция”.
Давайте изучим этот ответ получше, так как он поможет нам понять некоторые концепции, ожидающие нас в этой статье.
Байткод или машинный код
Очень важно понять разницу между байткодом и машинным (или нативным) кодом. Пожалуй, легче всего ее понять на примере:
— Cи компилируется в машинный код, который впоследствии запускается напрямую процессором. Каждая инструкция заставляет процессор производить разные действия.
— Java компилируется в байткод, который впоследствии запускается на Виртуальной машине Java (Java Virtual Machine, JVM), абстрактном компьютере, который запускает программы. Каждая инструкция обрабатывается JVM, который взаимодействует с компьютером.
Сильно упрощая: машинный код намного быстрее, но байткод лучше переносим и защищен.
Машинный код может отличаться в зависимости от машины, тогда как байткод одинаковый на всех машинах. Можно сказать, что машинный код оптимизирован под вашу конфигурацию.
Возвращаясь к CPython, цепочка операций выглядит следующим образом:
1. CPython компилирует ваш исходный код на Питоне в байткод.
2. Этот байткод запускается на виртуальной машине CPython.
Альтернативные виртуальные машины: Jython, IronPython и другие
Как я говорил выше, у Питона существует несколько реализаций. Опять же, как говори-лось выше, самой популярной является CPython. Эта версия Питона написана на C и считается имплементацией “по умолчанию”.
Но как насчет альтернатив? Одна из наиболее видных это Jython, реализация Питона на Java, которая использует JVM. В то время как CPython генерирует байткод для запуска на CPython VM, Jython генерирует байткод Java для запуска на JVM (это то же самое, что генерируется при компиляции программы на Java).
“Зачем может понадобиться использовать альтернативную реализацию?”, спросите вы. Ну, для начала, разные реализации хорошо ладят с разными наборами технологий.
CPython упрощает написание C-расширений для кода на Питоне потому что в конце он запускается интерпретатором Cи. Jython в свою очередь упрощает работу с другими программами на Java: вы можете импортировать любые Java-классы без дополнительных усилий, призывая и используя ваши Java-классы из программ на Jython. (Замечание: если вы еще не думали об этом всерьез, это довольно безумно. Мы дожили до того времени, когда можно смешивать разные языки и компилировать их в одну сущность. Как заметил Rostin, программы, смешивающие код на Фортране с Cи появились довольно давно, так что это не совсем новинка. Но это все же круто.)
В качестве примера, вот корректный код на Jython:
[Java HotSpot(TM) 64-Bit Server VM (Apple Inc.)] on java1.6.0_51
>>> from java.util import HashSet
>>> s = HashSet(5)
>>> s.add(«Foo»)
>>> s.add(«Bar»)
>>> s
[Foo, Bar]
Можно сказать, что Jython: Java :: IronPython: C#. Они работают на соответствующих виртуальных машинах, есть возможность импортировать классы C# в код IronPython и классы Java в код Jython, и так далее.
Кстати, хоть это и не станет причиной для перехода на другую имплементацию, стоит упомянуть, что имплементации эти на самом деле отличаются поведением. Это касается не только способов интерпретации кода на Питоне. Однако эти отличия, как правило, не-значительны, они исчезают и появляются со временем из-за активной разработки. К примеру, IronPython использует строки Unicode по умолчанию; однако CPython использует ASCII в версиях 2.x (выдавая ошибку UnicodeEncodeError для не-ASCII символов), и при этом поддерживает символы Unicode по умолчанию в версиях 3.x.
Компиляция на лету (Just-in-Time Compilation): PyPy и будущее
Итак, у нас есть имплементация Питона, написанная на Си, еще одна – на Java, и третья на C#. Следующий логичный шаг: имплементация Питона, написанная на… Питоне. (Подготовленный читатель заметит, что это утверждение немного обманчиво).
Вот почему это может сбивать с толку. Для начала, давайте обсудим компиляцию на лету (just-in-time или JIT).
JIT. Почему и как
Напомню, что нативный машинный код намного быстрее байткода. Ну, а что, если бы можно было компилировать часть байткода и запускать его как нативный код? Пришлось бы “заплатить” некоторую цену (иными словами: время) за компиляцию байткода, но если результат будет работать быстрее, то это здорово! Этим и мотивируется JIT-компиляция, гибридная техника, которая совмещает в себе преимущества интерпретато-ров и компиляторов. В двух словах – JIT старается использовать компиляцию, чтобы ускорить систему интерпретации.
Например, вот распространенный подход JIT:
В этом вся суть PyPy: использовать JIT в Питоне (в дополнении можно найти предыдущие попытки). Конечно, есть и другие цели: PyPy нацелен на кроссплатформенность, работу с небольшим количеством памяти и поддержку stackless (отказа от стека вызовов языка Си в пользу собственного стека). Но JIT это главное преимущество. В среднем на основе временных тестов, фактор ускорения составляет 6.27. Более подробные данные можно получить из схемы от PyPy Speed Center:
В PyPy сложно разобраться
У PyPy есть огромный потенциал, и в данный момент он хорошо совместим с CPython (так что на нем можно запускать Flask, Django, и т.д.).
Но с PyPy есть много путаницы. (оцените, к примеру, это бессмысленное предложение создать PyPyPy…). По моему мнению основная причина в том, что PyPy одновременно является:
1. Интерпретатором Питона, написанным на RPython (не Python (я обманул вас до этого)). RPython это подмножество Python со статичной типизацией. В Python, вести тщательные беседы о типах “в целом невозможно” почему это так сложно? рассмотрите следующее:
x = random.choice([1, «foo»])
это корректный код на Python (спасибо Ademan‘у). Какой тип у x? Как мы можем обсуждать типы переменных, когда типы даже не форсируются?). В RPython мы жертвуем некоторой гибкостью, но взамен получаем возможность гораздо проще управлять памятью и много чего еще, что помогает при оптимизации.
2. Компилятором, который компилирует код на RPython в разные форматы и поддерживает JIT. Платформой по-умолчанию является Си, то есть компилятор RPython-в-Си, но в качестве целевой платформы также можно выбрать JVM и другие.
Для простоты описания, я буду называть их PyPy (1) и PyPy (2).
Зачем могут понадобиться эти две вещи, и почему – в одном наборе? Думайте об этом так: PyPy (1) это интерпретатор, написанный на RPython. То есть он берет пользовательский код на Питоне и компилирует его в байткод. Но чтобы сам интерпретатор (написанный на RPython) мог работать, он должен быть интерпретирован другой реализацией Пи-тона, верно?
Итак, можно просто использовать CPython чтобы запускать интерпретатор. Но это будет не слишком быстро.
Вместо этого мы используем PyPy (2) (называемый RPython Toolchain) чтобы компилировать интерпретатор PyPy в код для другой платформы (например, C, JVM, или CLI) для запуска на конечной машине, с добавлением JIT. Это волшебно: PyPy динамически добавляет JIT к интерпретатору, генерируя собственный компилятор! (Опять же, это безумие: мы компилируем интерпретатор, добавляя другой отдельный, самостоятельный компилятор).
В конце концов результатом будет самостоятельный исполняемый файл, который интерпретирует исходный код на Питоне и использует оптимизацию JIT. То, что нужно! Понять сложновато, но, возможно, эта схема поможет:
Повторим: настоящая красота PyPy в том, что мы можем написать себе кучу разных интерпретаторов Питона на RPython не волнуясь о JIT (не считая пары деталей). После этого PyPy реализует для нас JIT, используя RPython Toolchain/PyPy (2).
На самом деле, если копнуть глубже в абстракцию, теоретически можно написать интерпретатор любого языка, направить его в PyPy и получить JIT для этого языка. Это возможно потому, что PyPy концентрируется на оптимизации самого интерпретатора, а не деталей языка, который тот интерпретирует.
В качестве отступления я бы хотел заметить, что сам JIT совершенно восхитителен. Он использует технику под названием “отслеживание” (tracing), которая работает следующим образом:
Узнать больше можно из этой легкодоступной и очень интересной публикации.
Подытожим: мы используем PyPy-компилятор RPython-в-Си (или другую целевую плат-форму), чтобы скомпилировать реализованный на RPython интерпретататор PyPу.
Заключение
Почему все это так восхитительно? Почему стоит гнаться за этой безумной идеей? По-моему, Алекс Гейнор объяснил это очень хорошо в своем блоге: “[За PyPy будущее] потому что [он] более быстрый, более гибкий и является лучшей платформой для развития Питона”.
Дополнение: другие названия, которые вы, возможно, слышали
Python 3000 (Py3k): альтернативное название Python 3.0, основной релиз Питона с обратной совместимостью, который появился в 2008. году. Команда Py3k предсказала, что новой версии понадобится примерно пять лет чтобы полностью прижиться. И в то время, как большинство (внимание: надуманное утверждение) разработчиков на Питоне продолжают использовать Python 2.x, люди все больше задумываются о Py3k.
Numba: “специализированный just-in-time компилятор”, который добавляет JIT в снабженный примечаниями код на Питоне. Проще говоря, вы даете ему подсказки, а он ускоряет некоторые части вашего кода. Numba является частью дистрибутива Anaconda набора пакетов для анализа и управления данными.
IPython: сильно отличается от всего, что мы обсудили. Вычислительная среда для Питона. Интерактивная, с поддержкой GUI-пакетов, браузеров и так далее.
Psyco: модуль расширения Питона, одна из первых попыток Питона в области JIT. Давно помечен как “неподдерживаемый и мертвый”. Главный разработчик Psyco Армин Риго сейчас работает над PyPy.