Доступен (http://morepypy.blogspot.com/2012/06/pypy-19-yard-wolf.html) релиз проекта PyPy 1.9 (http://pypy.org/), в рамках которого разрабатывается реализации языка Python, написанная на языке Python (используется статически типизированное подмножество RPython (http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#re...), Restricted Python). Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию Python на языке Си (CPython).
В новом выпуске, отмечено исправления ошибок, улучшение совместимости с Python-проектами, значительный прогресс (http://buildbot.pypy.org/numpy-status/latest.html) в обеспечении поддержки библиотекой для проведения научных расчётов numpypy, улучшение поддержки платформ Windows и Mac OS X, продолжение развития бэкэндов JIT для архитектур ARMv7 и PPC64. Из новшеств можно выделить реализацию метода мультиплексирования соединений select.kqueue с использованием механизма kqueue из FreeBSD и поддержку создания и манипулирования Си-подобными структурами, используя только модуль _ffi, который в отличие от ctypes более оптимален для работы JIT.
Кроме того, продолжена работа по увеличению производительности и снижению потребления памяти. В среднем PyPy 1.9 на 4% быстрее (http://speed.pypy.org/) PyPy 1.8 и в 5.5 раз быстрее классического CPython 2.7.2. Ценой высокой производительности и использования JIT-компиляции является более высокое потребление памяти - общее потребление памяти в сложных и длительно работающих процессах (например, при трансляции PyPy силами самого PyPy) превышает потребление CPython в полтора-два раза.
<center><a href="http://speed.pypy.org/"><img src="http://www.opennet.me/opennews/pics_base/33053_1328947713.pn... style="border-style: solid; border-color: rgb(233, 234, 214); border-width: 15px;" title="" border="0"></a></center>
Основные особенности 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 и ARMv7. Ведется работа по адаптации для архитектуры PowerPC (PPC64), но она ещё не завершена;
- На базе технологий PyPy созданы бэкенды для генерации в PyPy байткода для LLVM и виртуальных машин .NET/CLI и Java.
- На базе PyPy ведется разработка реализаций на языке Python интерпретаторов Prolog, Smalltalk, JavaScript, Io и Scheme.
URL: http://morepypy.blogspot.com/2012/06/pypy-19-yard-wolf.html
Новость: http://www.opennet.me/opennews/art.shtml?num=34070
а поддержка python3 есть?
>PyPy может быть использован для бесшовной замены CPython 2.7;Чукча не читатель, чукча — писатель?
А где STM? Сколько еще ждать?
а чё это такое?
http://ru.wikipedia.org/wiki/Программная_транзакционная_памятьВроде обещали запилить
Он в эксперементальном бранче. Но пока производительность от него только падает.
>Поддержка бесстекового (Stackless) режима работы, позволяющего использовать модель actor (erlang-подобное программирование с массой микропотоков и отсыланием сигналов друг другу, но при этом (в отличии от erlang) всё происходит в одном физическом потоке ОС);А вот это хреново!
Все нормально. Запускаете по интерпретатору на каждое ядро и общаетесь через очереди или пайпы.
Node.js-подобная фигня или я что-то путаю?
ты путаешь
Тот же GIL, только в профиль. И те же способы борьбы с ним.
надо пологать, предлашаешь на каждый питонообъект повесить по мьютексу?
Абсолютно не представляю внутренности питона - но erlang именно за счёт изоляции потоков и сообщений как единственного механизма обмена между ними не требует вешать мьютексы куда попало. Интересно, почему здесь так нельзя.P.S. А вообще - иметь какой-нибудь нормальный язык a-la erlang (с той же многопроцессной моделью и таким же тщательно вылизанным окружением от мониторинга до деплоя и апдейтов), но с нормальными локальными переменными было бы счастьем...
Elixir - http://elixir-lang.org/
В нём иммутабельные переменные
Причем здесь внутренности? Erlang чистый функциональный язык, а питон мультипарадигменный. Надоели придирки к gil.
А при чём парадигма к GIL? Если у вас модель share-nothing - зачем здесь GIL? Но, вероятно, вариант share-nothing для питона почему-то не подошел.
ernang так может делать лишь только из-за того, что он не GP яык и накладывает ряд ограничений на то что и как можно делать. И, кстати, это далеко не всегда эффективно, скорее фича распараллеливания для лентяев без прогнозируемого результата
Хм.. Это для меня что-то новенькое. И насчёт ограничений и насчёт "без прогнозируемого результата". Подробнее можно?
кстати так и не понял про оговорку "(в отличии от erlang)...". В erlang VM тоже не плодятся множество физических потоков. Они плодятся как минимум по количеству ядер, бывает немного больше, но в этой фразе подано так как будто "минипоток Эрланга = физический поток".
Больше того - Erlang VM много лет вполне комфортно жила, будучи однопоточной - но там, конечно, интеграция нод очень удобна и вариант "по VM на ядро" никаких проблем не создаёт.
Почему такая странная нумерация версий? Не понять, синтаксис какой ветки он поддерживает
Вовсе не странная. Это отдельный продукт, его не должны нумеровать шаг в шаг с cpython.
если взять и прочитать текст новости, то станет ясно с какой веткой он совместим
Всё ещё нужно 4 GiB RAM, чтобы его собрать?
Необязательно, можно 8, 12, 16...
надеюсь, когда-нибудь pypy станет мейнстримом
> но при этом (в отличии от erlang) всё происходит в одном физическом потоке ОСчто значит в отличии? erlang изначально обрабатывал всё в одном физическом потоке (кроме операцию i/o). режим smp с множеством потоков появился не так давно и это очень большое преимущество над всеми остальными платформами. "в отличии" несет негативный оттенок, что в корне неверно.