Доступен (http://morepypy.blogspot.co.uk/2013/05/pypy-20-einstein-sand...) релиз проекта PyPy 2.0 (http://pypy.org/), в рамках которого разрабатывается реализации языка Python, написанная на языке Python (используется статически типизированное подмножество RPython (http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#re...), Restricted Python).Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python 2.7 на языке Си (CPython). В среднем PyPy 2.0 на 4% быстрее (http://speed.pypy.org/) PyPy 1.9 и в 5.7 раз быстрее классического CPython 2.7.3. Ценой высокой производительности и использования JIT-компиляции является более высокое потребление памяти - общее потребление памяти в сложных и длительно работающих процессах (например, при трансляции PyPy силами самого PyPy) превышает потребление CPython в полтора-два раза.
<center><a href="http://speed.pypy.org/"><img src="http://www.opennet.me/opennews/pics_base/0_1368210321.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;" title="" border=0></a></center>
Стабильный релиз поддерживает x86-системы, включая Linux (32/64 бит), Mac OS X (64 бит) и Windows (32 бит). Одновременно проходит (http://morepypy.blogspot.co.uk/2013/05/pypy-20-alpha-for-arm...) альфа-тестирование вариант PyPy 2.0 для платформы ARM. Выпуск для ARM позиционируется как ознакомительный, так как версия для данной платформы ещё не совсем стабильна и не поддерживает некоторые возможности. В частности, ещё не реализована поддержка бесстекового режима и JIT не всегда корректно генерирует ассемблерный код. PyPy для ARM доступен для ARMv6 (Raspberry Pi) и ARMv7 (Beagleboard, Chromebook, Cubieboard) в режимах hard-float и soft-float.Новшества, добавленные в PyPy 2.0:
- Бесстековый режим доведён до работоспособного состояния. В том числе обеспечена поддержка элементов системы многопоточного программирования "greenlet (http://greenlet.readthedocs.org/)", а также возможность использования eventlet и gevent;- В состав PyPy включён новый встроенный модуль cffi (http://cffi.readthedocs.org/) с реализацией интерфейса для вызова функций, написанных на языке Си. Данный интерфейс позиционируется как рекомендуемый метод обращения к функциям на языке Си;
- Для обратных вызовов Python функций из Си-кода теперь применяется JIT-компиляция, что, например, позволило значительно ускорить выполнение модуля парсинга XML;
- Проведён рефакторинг JIT-компилятора для генерации машинного кода, оперирующего областями в куче, вместо стека. Подобное изменение позволило обеспечить работу бесстекового режима и открыло новые пути дальнейшей оптимизации;
- Переработана большая часть классов для работы с массивами из состава библиотеки numpypy, что позволило избавиться от лишних вычислений. Подготовлена более полная реализация dtype и обеспечена поддержка дополнительных атрибутов массивов;- Внесено множество оптимизаций производительности;
. On the other hand, we now have more complete dtype support and support more array attributes.Основные особенности PyPy:
- Поддержка бесстекового (Stackless) режима работы, позволяющего использовать модель actor (erlang-подобное программирование с массой микропотоков и отсыланием сигналов друг другу, но при этом (в отличии от erlang) всё происходит в одном физическом потоке ОС);
- Реализация режима изолированного выполнения кода, к которому нет доверия. От sandbox в CPython данный режим отличается полной поддержкой всех возможностей языка без выделения unsafe-функций.
- Автоматическая генерация и полная прозрачность встроенного JIT-компилятора;
- PyPy успешно проходит стандартный тестовый пакет Python и поддерживает (http://pypy.org/compat.html) большинство из стандартных Python-модулей и фреймворков, таких как ctypes, django (с sqlite), twisted (без поддержки ssl), pylons, pyglet. PyPy может быть использован для бесшовной замены CPython 2.7;
- Поддержка работы на архитектурах x86 (IA-32) , x86_64 и ARM. Ведется работа по адаптации для архитектуры PowerPC (PPC64), но она ещё не завершена;
- На базе технологий PyPy созданы бэкенды для генерации в PyPy байткода для LLVM и виртуальных машин .NET/CLI и Java.
- На базе PyPy ведется разработка реализаций на языке Python интерпретаторов Prolog, Smalltalk, JavaScript, Io и Scheme.
URL: http://morepypy.blogspot.co.uk/2013/05/pypy-20-einstein-sand...
Новость: http://www.opennet.me/opennews/art.shtml?num=36904
Отлично, ctypes замену прикрутили, а значит библиотеки можно будет прикручивать. Numpy помнится они почти собрали запрашиваемую сумму под проект. В общем, торт.
Ему всё так же требуется 4 гига для компиляции? Раздельную трансляцию модулей когда приладят?
вот это очень пичально на счёт 4х гб. Требудются они в самом конце при линковки, косяк на ровном месте
Кто-нибудь тестил Django на PyPy? Как оно по соотношению память/процессор в сравнении с cPython?
Зачем если есть ЖаваСкрипт?
плюсую
чем изобретать интерпретаторов для питонобэйсиков, сделали б годный серверный js
тогда необходимость во многих php/python/ruby отпадет сама сабой
минусую.
чем изобретать интерпретаторов для жабобейсиков, сделали б годный клиентский питон.
А для тех кто в танке - серверных жс и так уже сделано: хотя бы ноде.жс и рино. И чо? Язык, в котором нет даже printf, пусть идёт тёмным лесом.
Ну ты и лох.
node.js - годный, серверный, необходимость в php/python/ruby отпала сама собой. Поздравляю, ваше желание исполнилось!))
> node.js — годный, серверный…унылый и кривой. ничем не отличается от массы других костылей, где нет first class continuations.
велосипед JRE
LuaJIT как-то получше выглядит, да и побыстрей.
прув давай, мли gtfo
а зачем пруфы, сравнивающие *полную* реализацию языка (LuaJIT) и непонятного кастрата (PyPy)? кастрат проиграл уже только потому, что он кастрат. будь он даже быстрее всего на свете.
Ага - ЩАС! Твой Lua - кастрат от рождения, его даже полная версия с самой кастрированной ритошкой и рядом не лежала.
Впрочем - кастратам кастратво :)
как и полагается Иксперту, сравнениями и доказательствами он не утруждается. потому что Иксперт Всегда Изрекает Истину.
У LuaJIT не хватает "батареек", красивой многопоточности и зеленых потоков, так что сравнивать тут трудновато.
Если сравнивать непосредственно JIT-компилятор, то LuaJIT на данный момент является самым быстрым, эффективным и полнофункциональным из всего, что я видел. Если рассматривать всю экосистему целиком, то PyPy сейчас выглядит очень и очень здорово.
О каких именно батарейках речь? Интерфейсы вроде ко всему основному есть, модный веб-фреймворк вот недавно запилили тоже (Lapis). LPEG для парсеров, и прочие "тяжелые" вещи тоже вроде присутствуют. Ну а "вниз" вообще всё хорошо, см. тот же ljsyscall.
Питон на питоне? Оригинально! :-)
> Питон на питоне? Оригинально! :-)Дурак на OpenNet-e? Обыденно. Увы :(
>> Питон на питоне? Оригинально! :-)
> Дурак на OpenNet-e? Обыденно. Увы :(Ну ооочень умное замечание. Прямо таки ослепляющий интеллект анонима.
А насколько быстрее будет pypy если загрузить его используя pypy?
Даешь PyPyPy 1.0!
> Новшества, добавленные в PyPy 2.0:
> - Бесстековый режим доведён до работоспособного состояния. В том числе обеспечена
> поддержка элементов системы многопоточного программирования "greenlet (http://greenlet.readthedocs.org/)",
> а также возможность использования eventlet и gevent;eventlet работает, но там засада с версией zeromq, работающим с pypy.
gevent на данный момент не работает(к большому сожалению).самое приятное, что можно наконец-то запустить несколько потоков и все они задействуют несколько cpu.
а для перла есть такая штука?
Ждем ПеПе, РуРу и ПхПх?
> а для перла есть такая штука?мертвый же язык.
perl медленно живет, питон медленно умирает не родившись
Как может интерпритатор питона на питоне работать быстрее самого питона?
ИнтерпрЕтатор питона на питоне работает медленнее самого питона, быстрее питона работает код, сгенерированный интерпретатором питона на питоне, оснащенного JIT-компилятором питона на питоне
