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

В продолжение оффтопика

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

То был код для LispWorks. SBCL создал куда-более компактный (ниже). Я уж и не знаю что может быть эффективнее для динамического языка, когда нет прямого указания по типам. В примере сложение работает и на целых, и на комплексных числах.

Что касается более общего вопроса, то тут надо спрашивать mv. У него гораздо больше практики. Но мое видение такое, что типы применять нужно только в узких местах, а это эмпирически не более 2, максимум, 20 процентов кода.

А шутаут доверия не вызывает у меня. Как-то swizzard запостил туда самое эффективное и скоростное решение для одной задачи, так это решение удалили потом. Шутаут как мерялка хорош для Си-подобных языков, где ограниченные средства выражения. Лисп выглядит как неформат.

* (defun test (a b) (+ a b))

TEST
* (disassemble 'test)

; disassembly for TEST
; 0AFCA055:       8B55FC           MOV EDX, [EBP-4]           ; no-arg-parsing entry point
;       58:       8B7DF8           MOV EDI, [EBP-8]
;       5B:       E8F86003F6       CALL #x1000158             ; GENERIC-+
;       60:       7302             JNB L0
;       62:       8BE3             MOV ESP, EBX
;       64: L0:   8BE5             MOV ESP, EBP
;       66:       F8               CLC
;       67:       5D               POP EBP
;       68:       C3               RET
;       69:       CC0A             BREAK 10                   ; error trap
;       6B:       02               BYTE #X02
;       6C:       18               BYTE #X18                  ; INVALID-ARG-COUNT-ERROR
;       6D:       4F               BYTE #X4F                  ; ECX
NIL
dave ★★★★★
()
Ответ на: комментарий от dave

Больше интереса всё-таки вызывает не листинг 'test, поиграться со стеком невелика наука, а 'GENERIC-+.

И еще, отвлеченный вопрос, скорее всего я тупой. Где в следующем листинге намеки на 1, 2, 3, или откуда берется 6 в качестве результата?

0] (defun test () (+ 1 2 3))                                                 

STYLE-WARNING: redefining COMMON-LISP-USER::TEST in DEFUN
TEST
0] (disassemble 'test)
; disassembly for TEST
; 0AB3A7AE:       BA18000000       MOV EDX, 24                ; no-arg-parsing entry point
;       B3:       8BE5             MOV ESP, EBP
;       B5:       F8               CLC
;       B6:       5D               POP EBP
;       B7:       C3               RET
;       B8:       CC0A             BREAK 10                   ; error trap
;       BA:       02               BYTE #X02
;       BB:       18               BYTE #X18                  ; INVALID-ARG-COUNT-ERROR
;       BC:       4F               BYTE #X4F                  ; ECX
;       BD:       CC0A             BREAK 10                   ; error trap
;       BF:       02               BYTE #X02
;       C0:       18               BYTE #X18                  ; INVALID-ARG-COUNT-ERROR
;       C1:       4F               BYTE #X4F                  ; ECX

NIL

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

GENERIC-+ и есть динамика. Общее сложение для разных аргументов независимо от их реальных типов. Разве может быть что-то эффективнее для общей задачи, когда типы не определены?

А на твой второй вопрос ответ очень прост. Выражение (6 = 1 + 2 + 3) вычисляется во время компиляции и подставляется готовый результат ;)

Попробуй дизассемблировать (defun test2 () 6).

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

> Это все равно, что возмущаться ручным выделением в С.

Это даже хуже.

Ибо RAII в полный рост и при нормальном проектировании времени жизни объекта никакого «ручного выделения» (а, главное, освобождения), почитай, и нет вообще

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

Выражение вычисляется во время компиляции и подставляется готовый результат.

Я знал, я знал. Да, мне стыдно.

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

Ибо RAII в полный рост и при нормальном проектировании времени жизни объекта никакого «ручного выделения» (а, главное, освобождения), почитай, и нет вообще

А то, я на это, собственно, и намекал, что родовые травмы некоторым спать спокойно не дают.

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

Cython более элегантное решение, чем громоздкий PyPy. Cython легче поддерживать и развивать, ведь это компиляция в C и fallback к CPython если компиляция какой-то особенности языка ещё не реализована.

JIT в PyPy надо подгонять для всех процессоров. Разработка JIT, это трудоемкое занятие, человеческий фактор(если проект покинет специалист по jit, или ему надоест)...

Сам CPython изначально подразумевает быструю разработку и создание C-модулей для «узких участков». Cython эти модули генерирует из обычного кода python, но с возможностью добавления типов C, импорт C библиотек, и тд.

PyPy хороший проект, но по мне слишком JVM-подобен.

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

Опять, зачем их противопоставляешь? То что сейчас cython'овские модули не поддерживаются, так это вопрос времени.

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

Кому нужна быстрота от Python - смотрите на Shedskin.

Besides the typing restriction, programs cannot freely use the Python standard library (although about 22 common modules, such as random, itertools and re, are currently supported). Also, not all Python features, such as nested functions and variable numbers of arguments, are supported (see the documentation for details).

Уж лучше просто на RPython писать.

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

> Уж лучше просто на RPython писать.

Ну, так.. Чудес не бывает..
Я так решил, что если хочется чего-то необычного (в смысле не C/C++) и быстрого лучше D использовать.

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

> Уж лучше просто на RPython писать.

Кстати RPython так долго компилится и кушает память, что писать вы на нём точно не захотите.

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

It takes on the order of half an hour to finish the translation, and 2.x GB of RAM on a 32-bit system and 4.x GB on 64-bit systems. (Do not start a translation on a machine with insufficient RAM! It will just swap forever. See notes below in that case.)

офигенчик, у меня только 3гига на амд64 -_-

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

> А много в нем писать и не нужно.

Так даже пока helloworld скомпилиться устанешь ждать! Если бы это было хотя бы секунд 10, то куда нешло, но это порядка 5 минут!

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

Кроме того Helloworld на RPython выглядит совсем не так как Helloworld на Python. Там какие-то непонятные правила сборки кажется включаются в файл. В общем - хуже не придумаешь.

А прироста производительности как уверяют сами разработчики от такого самоограничения - с гулькин нос.

Поэтому чучуть лучше всё же переписать на shedskin, но ни в коем случае не на RPython.

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

Ну что там наговаривать, пять минут. Всего две.

python pypy/translator/goal/translate.py pypy/translator/goal/targetnopstandalone.py

[Timer] Timings:
[Timer] annotate                       ---   4.7 s
[Timer] rtype_lltype                   ---   2.9 s
[Timer] backendopt_lltype              ---   0.4 s
[Timer] stackcheckinsertion_lltype     ---   0.2 s
[Timer] database_c                     ---  79.2 s
[Timer] source_c                       ---  13.5 s
[Timer] compile_c                      ---  16.9 s
[Timer] ==========================================
[Timer] Total:                         --- 117.7 s

Поэтому чучуть лучше всё же переписать на shedskin

Если приспичит, я лучше cython возьму, доверия намного больше да и возможности пошире.

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

> Ну что там наговаривать, пять минут. Всего две.

Да, у меня P4 1.7 GHz. Да и 2 минуты - это катастрофически много для helloworld. А если вспомнить невнятные сообщения об ошибках RPython (разработчики об этом тоже предупреждают) - то вообще караул.

Если приспичит, я лучше cython возьму, доверия намного больше да и возможности пошире.


Ну, а зачем тогда RPython поминали?...

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

Ну, а зачем тогда RPython поминали?...

По глупости, конечно.

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

Возможно неверная, возможно я что-то неправильно делаю.

Я собстна побаловаться поставил. Оно не работает — баловаться неинтересено)

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

Блин, я теперь на целый день расстроен. Самолично ведь пилил туда мультииндексацию, так нет, выкинули. Она работала даже!

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

Cython - для написания сишных модулей на Python-like языке. PyPy - для ускорения Python. Что имеется в виду? Это же разные вещи. Кстати, чистый Python-код после Cython начинает тормозить только больше, тю к. оверхед на постоянные скачки Python-C. Я проверял. (Чистый Python - это без единого cdef, если чо). Минус генераторы, к слову, например.

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

Он же вроде помирал, не? Ну и опять, limited support of features.

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