The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Проект PyPy представил визуализатор процесса JIT-компиляции и обрисовал ситуацию, когда PyPy быстрее языка Си

15.08.2011 15:47

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

Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию CPython: при выполнении 20 тестов производительности PyPy в среднем опережает CPython в 4.3 раза. Несколько дней назад в блоге разработчиков PyPy была опубликована заметка, в которой разбиралась ситуация, когда PyPy может исполнять некоторые операции быстрее, чем их реализация на языке Си.

В частности, речь ведется о функциях форматирования строк. Как оказалось, разработчикам PyPy удалось увеличить производительность выполнения операций форматирования для конструкций на языке Python настолько, что удалось в два раза обогнать по скорости реализацию функции sprintf из стандартной библиотеки. При сборке с использованием GCC 4.5.2 и опции оптимизации "-O4", тестовый пример на языке Си был выполнен за 1.63 секунд (при выделении памяти не статически, а через malloc время выполнения увеличилось до 1.96 сек.) В то время как аналог на языке Python был выполнен с использованием PyPy за 0.85 сек. При запуске того же примера в CPython, на его выполнение было потрачено более 10 сек.

  1. Главная ссылка к новости (http://morepypy.blogspot.com/2...)
  2. OpenNews: Релиз PyPy 1.5, реализации Python, написанной на языке Python
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/31482-python
Ключевые слова: python, pypy, jit, optimization
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (29) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 16:01, 15/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Jango интересно PyPy поддерживает?
     
     
  • 2.6, арсен (?), 16:28, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    ИМХО ускорять Django приложения таким вот методом идеологически неверно, а? ;)
     

  • 1.2, Аноним (-), 16:02, 15/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +5 +/
    Сайт с online-демонстрацией лег.
     
  • 1.3, Аноним (-), 16:03, 15/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >и опции оптимизации "-O4"

    Чего-чего? И давно опции выше O3 реально производят какие либо оптимизации которых нет при O3?

     
     
  • 2.8, XVilka (ok), 16:55, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    ждем новости. питон обогнал хелловорлд написанный на си и скомпилированной с опцией -Over9000 :)
    Да, -O4 то же самое что и -O3
     
     
  • 3.17, Аноним (-), 18:58, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Пусть попробуют что-нибудь более полезное посчитать, тогда и меряются пиписьками. Допустим алгоритм сжатия или хеширования погонять. Сдается мне что там фичи питона сыграют с ним дурную шутку и сильно тормознут его в горячих циклах, так что никакой jit его не спасет. Ну примерно как яву, которая "не тормозит", но успешно сливает в 3 раза в среднем по больнице, из-за кучи "лишних" действий. Хотя разумеется можно при должном желании искусственно подогнанный пример где ява зарулит си :)
     
     
  • 4.37, mine (ok), 20:34, 18/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Про джаву и Си:
    Да спокойно: например, можно решать задачу "циклически ничего не делать в течении секунды". Тут джава справится за куда меньшее количество операций, нежели Си.
     

  • 1.7, Аноним (-), 16:47, 15/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >удалось в два раза обогнать по скорости реализацию функции sprintf из стандартной библиотеки

    А что именно за стандартная библиотека и с какими флагами она собрана указать забыли?

     
     
  • 2.12, Anonism (?), 18:00, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Не имеет значения что там за библиотека. Смысл вот в этих предложениях:

    This is clearly win for dynamic compilation over static - the sprintf function lives in libc and so cannot be specializing over the constant string, which has to be parsed every time it's executed. In the case of PyPy, we specialize the assembler if we detect the left hand string of the modulo operator to be constant.

     
     
  • 3.20, Аноним (-), 19:26, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > This is clearly win for dynamic compilation over static

    Да вааще, разгром полный. Нашли corner case и прикопались к нему. А пусть хоть умножение матриц реализуют и покажут как оно там заруливает? Или преобразование Фурье? Как, не хотите показать победу?

     
     
  • 4.21, Stax (ok), 19:35, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А что, есть претензии к скорости умножения матриц в numpy?

    А JIT'еный numpy в PyPy быстрее оригинального в сpython, пруф: http://morepypy.blogspot.com/2011/05/numpy-in-pypy-status-and-roadmap.html
    С FFT - ну возможно, питоновская обвязка для FFTW http://www.fftw.org/ будет быстрее fft в numpy. В любом случае, это "достаточно быстро".

     
     
  • 5.22, Аноним (-), 20:00, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Какого еще cpython? Тормозной конкурент специально выбран чтобы его показательно побить? А не хотите с си, если уж начали с ним сравниваться и утверждать что победа, бла-бла-бла?

    А "питоновская обвязка к" - не считается(FFTW is a C subroutine library): мы как бы хотим померять скорость сгенеренного *питоновского* кода. Дерг обвязки на сях - читерство и там скорость работы является заслугой *си* а не *pypy*, внезапно. А забабахайте FFT на вашем питоне, вот и посмотрим что там супер-jit нагенерит.

    > В любом случае, это "достаточно быстро".

    Достаточно быстро - это что-то типа 640Кб хватит всем? А то потоки данных бывают разные. Вплоть до сотен мегов в секунду с скоростного АЦП.

     
     
  • 6.27, Аноним (-), 21:43, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    С чего это вдруг не считается? Вы еще скажите, что скорость С — заслуга не самого С, а языка ассемблера, на котором написана немалая часть стандартной библиотеки. Факт в том, что в питоне возможно вычислять преобразование Фурье со скоростью, сравнимой с С. Или вы предлагаете программировать на любом языке, не используя никаких библиотек, кроме написанных на этом же языке? Так ведь уже упомянутая стандартная библиотека С не написана целиком на С. И далеко Вы без неё уедете?
     
  • 6.35, коксюзер (?), 01:24, 16/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В интернациональном комьюнити все бы давно сошлись во мнении, что авторы продемонстрировали интересный принцип и не более (во всяком случае пока). В русскоязычном - опять холисрач вокруг всем очевидных вещей, с возведением частного в общее и последующими проекциями на авторов PyPy.
     

  • 1.9, aaa (??), 16:58, 15/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Для желающих поэкспериментировать с Jitviewer без локальной установки представлена online-демонстрация.

    Это надо было отдельной новостью:

    "Группа энтузиастов представила сообществу реализацию Jitviewer, выполненную на JavaScript. Jitviewer представляет собой для визуализации процесса преобразования Python-кода в ассемблерный JIT-компилятором, встроенным в PyPy - реализацию интерпретатора питона на питоне".

     
  • 1.10, nmorozov (ok), 17:25, 15/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    т.е все их оптимизации, это написание более быстро sprintf...
     
     
  • 2.29, Аноним (-), 22:06, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А чего в этом плохого? Лучше быстрее, чем медленнее. Хотя, конечно, это моё субьективное мнение. Мало ли, вдруг за последние годы ценности изменились, и высокая скорость считается пороком.
     

  • 1.13, Аноним (-), 18:11, 15/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Лол, в C++0x можно сделать sprintf на шаблонах, будет ещё быстрее. А вообще если оно специализирует каждый конкретный вызов sprintf, надо учесть затраты на собственно компиляцию, и ещё интересно сколько он жрёт памяти.

    Но вообще, направление правильное, т.к. нет великого зла - виртуальной машины.

     
     
  • 2.39, mine (ok), 20:40, 18/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А куда она делась? Она же внизу лежит, в интерпретаторе самого pypy...
     

  • 1.14, all_glory_to_the_hypnotoad (ok), 18:23, 15/08/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Разработчики проекта PyPy, в рамках которого развивается _реализация_ _языка_ _Python_ _со_ _статической_ _типизацией_

    э... ничего не порвалось?

     
     
  • 2.19, Аноним (-), 19:03, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Всё правильно делают. Динамическая типизация не нужна.
     
     
  • 3.25, all_glory_to_the_hypnotoad (ok), 20:56, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    попробую поставить вопрос иначе. Где там статическая типизация?
     
     
  • 4.28, Аноним (-), 21:47, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Нигде. Автор новости просто перепутал. Наверное, с Cython. Там статическая типизация есть. Впрочем, динамическую тоже вроде бы никто не выбрасывал.
     
     
  • 5.31, Аноним (-), 22:15, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > Впрочем, динамическую тоже вроде бы никто не выбрасывал.

    В новости все верно написано. Как вы собрались динамическую типизацию компилировать в JIT-е ?

     
     
  • 6.32, Аноним (-), 22:29, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так же, как компилируют полиморфизм в плюсах и прочих языках, где оный используется, когда статической типизации не хватает, а признаться в этом стыдно.
     
  • 4.30, Аноним (-), 22:14, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > попробую поставить вопрос иначе. Где там статическая типизация?

    В PyPy используется диалект RPython (Restricted Python), который поддерживает только статические типы и не допускает менять тип уже определенной переменной.

    http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#our-runtime-interpr

    "Unlike standard Python, RPython is statically typed, to allow efficient compilation"

     
     
  • 5.33, all_glory_to_the_hypnotoad (ok), 22:55, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > В PyPy используется диалект RPython (Restricted Python), который поддерживает только статические типы

    понимаешь ли.. это не статическая типизация, а оптимизация для JITа.

     
  • 4.36, коксюзер (?), 01:26, 16/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > попробую поставить вопрос иначе. Где там статическая типизация?

    В диалекте RPython.

     
  • 3.26, Аноним (-), 21:12, 15/08/2011 [^] [^^] [^^^] [ответить]  
  • +/
    я тоже хочу знать что из себя представляет статическая типизация в Python, просто приведите пример кода и всё, больше ничего не нужно
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру