Публикации с меткой «pypy»

Доброе время суток!

Так уж сложилось, что я занимаюсь всякими разнообразными push технологиями с использованием Tornado. Чуть ранее описывал Tornadio2, серверную реализацию протокола socket.io поверх Tornado.

Теперь хочу представить похожий проект — sockjs-tornado.

Для тех кому не очень интересно, есть другая полезная информация: сравнительное нагрузочное тестирование PyPy 1.7 против CPython 2.6.6, sockjs-node и socket.io (оба на node.js 0.6.5). Все под катом :-)

Вышел релиз проекта PyPy 1.6, в рамках которого разрабатывается реализации языка Python, написанная на языке Python

P.S. Не могу оформить как топик-ссылку, пришлось так.

Разработчики проекта PyPy, в рамках которого развивается реализация языка Python со статической типизацией, написанная на языке Python и активно использующая JIT-компиляцию, представили систему jitviewer. Jitviewer представляет собой инструментарий для визуализации процесса преобразования кода

P.S. Не могу оформить как топик-ссылку, пришлось так.

Все исходные коды и примеры из этой статьи доступны здесь.

Когда я первый раз смотрел проект PyPy, мне потребовалось некоторое время, чтобы выяснить, что он из себя представляет. Он состоит из двух вещей:

— набор инструментов для написания интерпретаторов языков программирования;
— реализация Питона с применением этого набора инструментов.

Вероятно, большинство людей думает, что PyPy это только вторая часть, но это руководство не об интерпретаторе Питона. Оно о том, как написать интерпретатор своего языка.

Я взялся за это руководство для того, чтобы лучше понять как работает PyPy и что он из себя представляет. Предполагается, что вы очень мало знаете о PyPy, поэтому я начну с самого начала.

PyPy теперь умеет загружать и запускать расширения CPython'а (то есть, .pyd и .so файлы) напрямую, при помощи новой подсистемы, которая называется CPyExt. В отличие от решения, представленного в другом блог-посте (в котором модули расширения типа numpy запускались на CPython и проксировались через TCP), новое решение больше не требует запущенного CPython. Мы пока ещё не достигли полной бинарной совместимости (как Ironclad), но, в большинстве случаев, достаточно просто перекомпилировать расширение.

Единственное требование — необходимые функции C API из CPython должны быть реализованы в PyPy. Если вы пользователь или автор модуля, и вам не хватает некоторых функций в PyPy, мы приглашаем вас их реализовать. Уже довольно много людей (включая много новых контрибьюторов) уже включились в разработку и реализовали некоторые функции для того, чтоб их любимые модули заработали. В конце поста — список имён.

Кстати о скорости. Несмотря на то, что существуют накладные расходы на запуск этих модулей, когда мы запускаем движок регулярных выражений из CPython (_sre.so) и проходим бенчмарк spambayes из набора бенчмарков Unladen Swallow (см speed.pypy.org), то получаем значительное ускорение: тест стал вдвое быстрее по сравнению с движком регулярок, встроенным в PyPy. Из закона Амдала следует, что _sre.so должен работать в несколько раз быстрее, чем встроенный движок.

В данный момент идёт работа над PIL и другими модулями. Например, поддержка distutils уже почти завершена. И если вы хотите участвовать в этом или получить больше информации о том, как использовать эту новую возможность, заходите на наш IRC-канал #pypy на freenode.

Вышел PyPy 1.2. Основное отличие — наличие JIT компилятора.
Чтобы долго не объяснять что это и зачем — простой тест:

cnt = 10 * 1000 * 1000
for _ in xrange(cnt): 
    i = i + 1

5.8млн операций сложения в секунду на обычном СPython 2.6 (python test.py)
42.5млн операций в секунду на PyPy 1.2 (pypy test.py)
WinXP SP3, Core2Duo.

Да, в 7 раз быстрее он тест сделал! И это не только на синтетическом тесте: «django» в 3 раза быстрее, «n-body» в 7 раз быстрее… Я не знаю что такое тест «richards», но он теперь вообще в почти 12 раз быстрее. Смотрите результаты сами.

Читать и качать (из раздела "«JIT compiler» version"). 64-bit версии пока нет. А unladen-swallow нервно курит... Под катом еще несколько невероятностей («песочница для python кода»)…

Краткий перевод обсуждения Recommendation against Python?:

kng
Я слышал, что сотрудникам Google не рекомендуют использовать Python для новых проектов, что мне кажется глупым, учитывая как много питоновского кода и поддержки самого языка Python исходит из Google. Я начал поиски информации, но ничего не нашел. Вы знаете что-то об этом или это просто слухи?

Collin Winder
Даже простой здравый смысл ограничивает применимость Python, когда речь идет о масшабах Google — он не так быстр как Java или C++, работа с тредами хромает, расходуется больше памяти и т.д. Одно из требований, с которым мы сталкиваемся при проектировании новых систем, это «Что мы будем делать, если нагрузка возрастет в 10 или в 100 раз? Что мы будем делать, если целая планета решит что наш новых сервис офигителен?» Любая технология, которая усложняет соблюдение этого требования — и я считаю, что Python попадает в эту категорию — должна быть отвергнута и даже прочие её полезности не играют важной роли в этом случае. Приходится балансировать слабые и сильные стороны Python — ваши разработчики могут быть более продуктивными, используя Python, но если им придется крепко поработать над масштабированием под большую нагрузку, то удастся ли вам вырваться с Python вперед? И т.д.
…
Unladen Swallow планирует сместить этот баланс — чтобы сделать возможным использовать Python в большем числе проектов, где сейчас его использовать еще нерационально. Но панацеей это не будет. Python все еще будет медленнее, чем C или Java, будет использовать больше памяти и ужасно работать с тредами, пока кто-нибудь не решит инвестировать ресурсы в Python в объеме, сравнимом с ресурсами, которые Sun инвестировала в JVM. Я надеюсь, что внимание к производительности Python со стороны разработчиков будет носить лавинообразный характер — чем больше компаний будет заинтересовано в этом, тем больше ресурсов будет инвестировано, тем больше аспирантов будут работать над Python (и выкладывать результаты своей работы) и т.д.

Идея следующая — взять pypy, скомпилировать его с помощью pycow и посмотреть что получится. Результатом должен полный набор стандартных библиотек python которые можно будет запользовать как для sculpt так и для pycow .

Единственное что сдерживает — непонятка с алгоритмом работы import. В том плане что ни в sculpt, ни в pycow import не реализован вообще.

И это обоснованно — потому что действительно неочевидно — как организовывать import в удаленный клиент. Плодить кучу файлов и переспрашивать их с помощью XmlHttpRequest — плохо, потому как много запросов. Упаковывать весь python в один файл — тоже ни разу некомильфо, потому как получится один большой файл, в котором будет много лишнего.

Некоторым из вас, возможно, будет интересно узнать, что более 900 уникальных участников было задествовано в разработке Django, начиная с 1 января 2007 года. Данные основаны на логах SVN.
Должен заметить, что сообщество очень сильное, особенно в сравнеии с другими, широко известными проектами:

• Django: 906
• Pylons: 80
• PyPy: 240
• Linux Kernel: 4043
• PostgreSQL: 150
• Apache HTTP server: 118
• SQLAlchemy: 36
• Python: 428

Необходимо учесть, что все анонимные и гостевые коммиты считались за одного участника, если конечно проект позволял таковые.

Между тем Jython достиг реализации спецификации Python2.2 [>>>]. Пока что только бета, но we call it 'beta' cause it's much betta than nothing.

Собственно Jython это реализация языка Python для JVM. Идея кажется мне странной, но вот Microsoft поддерживает проект IronPython - реализацию питона для .NET.

Да, вам не показалось. Это оптимизирующий компилятор Python -> C++ -> Бинарный код. Результаты работают очень быстро, но за все приходится платить - ShedSkin понимает только очень небольшой сабсет языка Python. Изменения в версии 0.0.20:

• улучшена работа со списками и словарями
• поправлена работа операций целочисленного деления (/, //, divmod, floordiv), так чтобы они работали по схеме CPython2.5
• преобразование float в str аналогичное CPython
• масса исправлений в коде самого компилятора
• починена наконец то работа с self в статических методах.

Таким образом как вы понимаете работы еще вагон и маленькая тележка, но уже сейчас это очень полезный инструмент. [>>>]

Не смотря на идиотское с точки зрения русского человека название (впрочем zope это еще круче) PyPy это просто реализация языка Python на самом языке Python. Не спрашивайте зачем - лучше почитайте обзор изменений в версии 0.99.0 [>>>].