LINUX.ORG.RU

PyPy 1.6 — новые рекорды

 , ,


0

3

PyPy — достаточно совместимый Python интерпретатор, является почти полной заменой CPython 2.7.1, а благодаря трассирующему JIT-компилятору превосходит его по скорости.

Главными особенностями этого релиза стали скорость и стабильность. В среднем тесты производительности показывают, что PyPy 1.6 стал на 20-30% быстрее предыдущей версии, которая уже оставляла далеко позади CPython.

Это стало возможным вследствие комплексных изменений, улучшены Garbage Collector (GC), время разогрева JIT и проводимые им оптимизации, качество генерируемого машкода и реализация собственно интерпретатора.

В этой версии:

  • улучшено поведение GC на очень больших объектах и массивах;
  • ускорен ctypes: теперь вызовы оптимизируются JIT и до 60 раз быстрее чем в PyPy 1.5 и в 10 раз быстрее чем в CPython;
  • простые генераторы теперь разворачиваются в цикл по месту вызова, что дает прирост производительности в 3.5 раза, остальные генераторы были тоже оптимизированы и теперь быстрее на 10-20%, чем в PyPy 1.5;
  • поддержка плавающих одинарной точности в JIT, например array('f');
  • улучшен формат хранения словарей в зависимости от их содержимого, что дало прирост скорости и уменьшение расхода памяти, например, для словарей, у которых ключи только строки или целые; размеры остальных словарей также были уменьшены, благодаря исправленным ошибкам;
  • в поставку включен JitViewer — веб-инструмент, помогающий узнать какие части приложения были затронуты JIT, вплоть до ассемблера;
  • расширен список поддерживаемых C-модулей;
  • появились многобайтные кодировки;
  • первоначальная поддержка NumPy (теперь он очень быстр), интегрированная с JIT; к сожалению, API пока не полный и не каждое приложение сможет работать.

Анонс

>>> Страница загрузки

★★★

Проверено: Shaman007 ()
Последнее исправление: baverman (всего исправлений: 8)

Ответ на: комментарий от dizza

Забавно, ведь JIT более актуален для динамических языков.

Но реализация на порядок сложнее, чем для статически-типизируемых.

Я ведь правильно понял, что в статье под интерпретируемыми языками имеют в виду динамические?

Да.

baverman ★★★
() автор топика
Ответ на: комментарий от dizza

> Забавно, ведь JIT более актуален для динамических языков.

...но самый распространенный и вылизанный JIT сделан для Явы.

tailgunner ★★★★★
()

А кто-нибудь пробовал tkinter установить , у меня не получилось выдает ошибку


Processing tkinter-pypy-0.1.tar.gz
Running tkinter-pypy-0.1/setup.py -q bdist_egg --dist-dir /tmp/easy_install-Xr6hMK/tkinter-pypy-0.1/egg-dist-tmp-2ep3b_
src/_tkinter.c:74:17: fatal error: tcl.h: Нет такого файла или каталога
compilation terminated.
error: Setup script exited with error: command 'cc' failed with exit status 1

yanka ★★
()
Ответ на: комментарий от dizza

Ерунда.

Там есть тип «скомпилированная функция», если ты на нее посмотришь, то увидишь двоичный код. Но если ты специализируешь типы, то код будет оптимизирован. Можно функцию не компилировать, тогда она будет интерпретироваться.

anonymous
()
Ответ на: комментарий от anonymous

Но не бесконечно рекурсивным бутстрапом.

buddhist ★★★★★
()

И IDLE замечательно работает, но шрифты там - это ужас)))

./bin/pypy -m idlelib.idle

yanka ★★
()
Ответ на: комментарий от Xroft

Тогда по-моему удачный гибрид Питона, Руби и Шарпа.

У таких поделок только одно применение: облегчить жизнь питонистам в чужой среде. Да и то сомнительно очень.

Для чего он нужен?. Мелкие скрипты? Нет, vm слишком долго стартует. Клей для сишных библиотек? Нет, по очевидным причинам. Веб-разработка? Нет, где фреймворки? Средство быстрого прототипирования? Опять фейл, на чистом шарпе ничуть не сложнее это делать.

baverman ★★★
() автор топика
Ответ на: комментарий от dizza

> Для чисто динамического лиспа нету компилятора.

Как это нету?

CL-USER 1 > (defun test (a b) (+ a b))
TEST

CL-USER 2 > (disassemble 'test)
21AC898A:
       0:      89E6             move  esi, esp
       2:      81CEFCFF0F00     or    esi, FFFFC
       8:      3966D0           cmp   [esi-30], esp
      11:      7321             jnb   L1
      13:      80FD02           cmpb  ch, 2
      16:      751C             jne   L1
      18:      55               push  ebp
      19:      89E5             move  ebp, esp
      21:      8B7D08           move  edi, [ebp+8]
      24:      89FB             move  ebx, edi
      26:      0BD8             or    ebx, eax
      28:      F6C303           testb bl, 3
      31:      7512             jne   L2
      33:      89FB             move  ebx, edi
      35:      03D8             add   ebx, eax
      37:      700C             jo    L2
      39:      FD               std   
      40:      89D8             move  eax, ebx
      42:      C9               leave 
      43:      C20400           ret   4
L1:   46:      E8C51865FE       call  2011A282         ; #<Function RUNTIME:BAD-ARGS-OR-STACK 2011A282>
L2:   51:      897D08           move  [ebp+8], edi
      54:      C9               leave 
      55:      E91C0265FE       jmp   20118BE2         ; #<Function SYSTEM::*%+$ANY-STUB 20118BE2>
      60:      90               nop   
      61:      90               nop   
NIL

CL-USER 3 > 
dave ★★★★★
()
Ответ на: комментарий от baverman

> AFAIK, там нет никаких проблем с впиливанием поддержки для третьей версии.

Просто основной вектор разработки сейчас — вылизывание jit и совместимость с сишными модулями, что есть правильно и хорошо.


Большое спасибо :)

eReSik ★★
()

пардоньте за вопрос, оно уже умеет werkzeug, jinja2, psycopg2, sqlalchemy и flask?

anonymous
()
Ответ на: комментарий от anonymous

> Strong Static Type Checking for Functional Common Lisp by Robert L. Akers, University of Texas at Austin.

Это компилятор, написанный 50 лет назад? %)

tailgunner ★★★★★
()

А можно ли на питоне реализовать программный синтезатор, так чтобы принимать сигналы от миди-клавиатуры, генерить некий звук и воспроизводить его, и как можно с меньшими задержками?

anonymous
()
Ответ на: комментарий от anonymous

АПВС?

Каждой задаче свои инструменты. Разумно было бы написать привязки к существующим библиотекам.

anonymous
()

Кто-то может протестить новую и предыдущую версию на бенчмарке pystone?

anonymous
()

Отлично.

Только я все равно не понимаю, зачем нужны динамически типизированные языки.

Ведь есть же type inference.
И при наличии в статически типизированном языке чего-нибудь вроде интерфейсов, а так же возможности их пересекать и имплементировать отдельно от объявления класса/типа, он дает также много свобод, что и динамически типизированный, но при этом намного безопаснее, и для него проще соорудить компилятор.

Посмотрите, например, на haskell

anonymous
()
Ответ на: комментарий от anonymous

> для него проще соорудить компилятор.

Глупости. Компилятор динамического языка по определению проще - он может отложить все проверки на рантайм.

tailgunner ★★★★★
()

Наверное надо отметить в новости, что PyPy - это в первую очередь инструментарий для создания интерпретаторов языков программирования и JIT, а не просто «ещё одна очень быстрая реализация Python».

neuron
()
Ответ на: комментарий от dave

Я имел в виду, что нету нормального, эффективного компилятора. То, что ты привел - тривиальный случай. Я сужу чисто по CL исходникам debian shootout - они напичканы декларациями типов. Лень проверять, но если их по удалять, то производительность будет сильно хуже.

dizza ★★★★★
()
Ответ на: комментарий от anonymous

На динамически типизированных языках код проще получается. В хаскеле нужно писать кучу бюрократии для удовлетворения компилятора. Конечно, нету такого уровня статических проверок. Но если судить на примере питона, во-первых код в силу простоты нужно меньше рефакторить, во-вторых хорошие программисты пишут юнит-тесты, а не полагаются на проверку типов.

а так же возможности их пересекать и имплементировать отдельно от объявления класса/типа, он дает также много свобод, что и динамически типизированный

Все же это сложнее, чем просто полагаться на соглашения о наличии методов, чем вручную прописывать интерфейсы.

dizza ★★★★★
()
Ответ на: комментарий от anonymous

Зачем экзотика? Смотрите на D. Там во многих случаях вообще не имеет смысла статический тип приводить, потому что там шаблонное чудо на две строки. Зато на этом получаются исключительно эффективные и мощные контейнеры и алгоритмы.

anonymous
()
Ответ на: комментарий от baverman

>И на чем же написаны современные компиляторы С?

Видимо мой тонкий троллинг никто не оценил. Старею видимо...

vasya_pupkin ★★★★★
()

Вот почему в тексте новости про очередной JIT-компилятор нет списка архитектур, на которых он в данный момент работает? JIT-компиляторы являются непортабельными априори, поэтому эта информация очень важна.

Так бы я спокойно проигнорировал эту новость, ибо:

This release supports x86 machines running Linux 32/64 or Mac OS X. Windows 32 is beta (it roughly works but a lot of small issues have not been fixed so far). Windows 64 is not yet supported.

Перевожу. Хардверная платформа: архитектура — только x86 (я отношу к x86 процессоры x86 любой разрядности, как и авторы этого pypy, и это правильно). Софтверная платформа: Linux, OS X, в процессе поддержка оффтопик-недоОС.

powerpc
()
Ответ на: комментарий от anonymous

У них там в багтрекере, афаик, было 300+ Issues после последнего релиза.

Да и блин, API ломают каждые полгода.

Ты правда советуешь его использовать прямо сейчас?

anonymous
()
Ответ на: комментарий от baverman

А по-моему достаточно интересная идея. Ты говоришь, что он «не нужен» в основном потому, что для него нет нужных библиотек и инструментария, но ведь и для питона они не сразу появились. Молодой же язык, в конце концов. И в описании есть достаточно вкусные вещи (По крайней мере так кажется лично мне).

Кстати,

The Cobra compiler is implemented in Cobra

anonymous
()

Закопайте это поделие для непризнанных кульхацкеров.

Есть Java. Остальное в прикладном программировании не нужно.

Bioreactor ★★★★★
()
Ответ на: комментарий от Bioreactor

за базар надо отвечать ...

>Есть Java. Остальное в прикладном программировании не нужно.

А что уважаемый «полковник» подразумевает под прикладным программированием ??

MHz
()
Ответ на: комментарий от Bioreactor

Дартаньян, вы?

По сути вопроса конструктивные мысли\аргументы есть, или так, набросить баттхёртца захотелось?

anonymous
()
Ответ на: комментарий от yanka

> Скачивала pypy и пыталась тестировать простейшие скрипты на скорость исполнения , может я что-то делала не так но стандартная реализация python выполняла их быстрее.

jit прогревается долго. Надо брать долгоиграющие скрипты, там весь профит.

shimon ★★★★★
()
Ответ на: комментарий от Bioreactor

> Есть Java. Остальное в прикладном программировании не нужно.

Я лучше возьму Jython. У Java ровно одно преимущество — индусы успели наклепать туеву хучу компонентов, которую ты можешь с гордым видом собирать как конструктор для трехлетних детей (пофигу, что оно глючит, так как индусокод).

Если для простейших вещей в жабе надо пейсать такую тонну boilerplate'а, что все вокруг используют кодогенерацию (а некоторые даже не представляют, что можно иначе), то в жопу такой язык.

shimon ★★★★★
()
Ответ на: комментарий от shimon

Немного устаревшие аргументы. Сейчас java-фанбои ответят примерно следующее: «Scala — это императивный, менее многословный, чем java, язык с большим количеством функциональных плюшек, и за ним будущее.»

anonymous
()
Ответ на: комментарий от anonymous

> Немного устаревшие аргументы. Сейчас java-фанбои ответят примерно следующее: «Scala — это императивный, менее многословный, чем java, язык с большим количеством функциональных плюшек, и за ним будущее.»

Ага, и нормально могут его использовать полтора программиста.

Jython хотя бы привлекает портабельностью — если слишком сильно не привязываться к проприетарным или даже просто Java-only компонентам, я код могу на любом рантайме воротить. Хочу — на CPython запущу, хочу — на PyPy, хочу — золотые зубы вставлю. А вот Scala приварена к жабе намертво.

А еще я могу взять свои уже существующие знания питона, да скрестить с ВНЕЗАПНО доступными мне из него классами на Java, с интроспекцией и всем-всем-всем. И это безо всяких там public static hardcore fucking void main и прочей ненужной уйни.

shimon ★★★★★
()

Развивается, может скоро и CPython по популярности уделает.

lucentcode ★★★★★
()
Ответ на: комментарий от tailgunner

>Ты еще скажи, что ты не потроллить пришел.

Нет, мне правда непонятно почему тормоза питона считаются проблемой. Это все равно, что возмущаться тормозами bash'а.

AST-PM-105
()
Ответ на: комментарий от AST-PM-105

Нет, мне правда непонятно, почему ручное выделение памяти в C++ считается проблемой. Это все равно, что возмущаться ручным выделением в С.

baverman ★★★
() автор топика
Ответ на: комментарий от AST-PM-105

Мне продолжать передразнивать, или, наконец, уже осознаешь, что жестко тупишь?

baverman ★★★
() автор топика

А Cython, оно, судя по всему, так и не поддерживает. Интересно, будут ли какие-нибудь подвижки в этом направлении?

anonymous
()
Ответ на: комментарий от Bioreactor

скрипты писать на яве?? Питон в разы проще/удобнее.

не нравится многословность - public static void main(String[] args){}

main на пол экрана. Проще на плюсах тогда писать

RA
()
Ответ на: комментарий от AST-PM-105

Ну если есть возможность ускорить не в ущерб удобству то почему бы и нет?

RA
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.