Разработчики проекта PyPy (http://pypy.org/), в рамках которого развивается реализация языка Python со статической типизацией, написанная на языке Python и активно использующая JIT-компиляцию, представили (http://morepypy.blogspot.com/2011/08/visualization-of-jitted...) систему jitviewer (https://bitbucket.org/pypy/jitviewer/). Jitviewer представляет собой инструментарий для визуализации процесса преобразования кода встроенным JIT-компилятором, что дает возможность наглядно разобраться, какой именно Python-код и как компилируется в ассемблерное представление. Для желающих поэкспериментировать с Jitviewer без локальной установки представлена online-демонстрация (http://wyvern.cs.uni-duesseldorf.de:5000/).
Благодаря задействованию JIT-компилятора, на лету транслирующего некоторые элементы в машинный код, минуя фазу интерпретации байткода в виртуальной машине, PyPy при выполнении некоторых операций в несколько раз обгоняет по производительности классическую реализацию CPython: ...URL: http://morepypy.blogspot.com/2011/08/visualization-of-jitted...
Новость: http://www.opennet.me/opennews/art.shtml?num=31482
Jango интересно PyPy поддерживает?
ИМХО ускорять Django приложения таким вот методом идеологически неверно, а? ;)
Сайт с online-демонстрацией лег.
>и опции оптимизации "-O4"Чего-чего? И давно опции выше O3 реально производят какие либо оптимизации которых нет при O3?
ждем новости. питон обогнал хелловорлд написанный на си и скомпилированной с опцией -Over9000 :)
Да, -O4 то же самое что и -O3
Пусть попробуют что-нибудь более полезное посчитать, тогда и меряются пиписьками. Допустим алгоритм сжатия или хеширования погонять. Сдается мне что там фичи питона сыграют с ним дурную шутку и сильно тормознут его в горячих циклах, так что никакой jit его не спасет. Ну примерно как яву, которая "не тормозит", но успешно сливает в 3 раза в среднем по больнице, из-за кучи "лишних" действий. Хотя разумеется можно при должном желании искусственно подогнанный пример где ява зарулит си :)
Про джаву и Си:
Да спокойно: например, можно решать задачу "циклически ничего не делать в течении секунды". Тут джава справится за куда меньшее количество операций, нежели Си.
>удалось в два раза обогнать по скорости реализацию функции sprintf из стандартной библиотекиА что именно за стандартная библиотека и с какими флагами она собрана указать забыли?
Не имеет значения что там за библиотека. Смысл вот в этих предложениях: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.
> This is clearly win for dynamic compilation over staticДа вааще, разгром полный. Нашли corner case и прикопались к нему. А пусть хоть умножение матриц реализуют и покажут как оно там заруливает? Или преобразование Фурье? Как, не хотите показать победу?
А что, есть претензии к скорости умножения матриц в numpy?А JIT'еный numpy в PyPy быстрее оригинального в сpython, пруф: http://morepypy.blogspot.com/2011/05/numpy-in-pypy-status-an...
С FFT - ну возможно, питоновская обвязка для FFTW http://www.fftw.org/ будет быстрее fft в numpy. В любом случае, это "достаточно быстро".
Какого еще cpython? Тормозной конкурент специально выбран чтобы его показательно побить? А не хотите с си, если уж начали с ним сравниваться и утверждать что победа, бла-бла-бла?А "питоновская обвязка к" - не считается(FFTW is a C subroutine library): мы как бы хотим померять скорость сгенеренного *питоновского* кода. Дерг обвязки на сях - читерство и там скорость работы является заслугой *си* а не *pypy*, внезапно. А забабахайте FFT на вашем питоне, вот и посмотрим что там супер-jit нагенерит.
> В любом случае, это "достаточно быстро".
Достаточно быстро - это что-то типа 640Кб хватит всем? А то потоки данных бывают разные. Вплоть до сотен мегов в секунду с скоростного АЦП.
С чего это вдруг не считается? Вы еще скажите, что скорость С — заслуга не самого С, а языка ассемблера, на котором написана немалая часть стандартной библиотеки. Факт в том, что в питоне возможно вычислять преобразование Фурье со скоростью, сравнимой с С. Или вы предлагаете программировать на любом языке, не используя никаких библиотек, кроме написанных на этом же языке? Так ведь уже упомянутая стандартная библиотека С не написана целиком на С. И далеко Вы без неё уедете?
В интернациональном комьюнити все бы давно сошлись во мнении, что авторы продемонстрировали интересный принцип и не более (во всяком случае пока). В русскоязычном - опять холисрач вокруг всем очевидных вещей, с возведением частного в общее и последующими проекциями на авторов PyPy.
> Для желающих поэкспериментировать с Jitviewer без локальной установки представлена online-демонстрация.Это надо было отдельной новостью:
"Группа энтузиастов представила сообществу реализацию Jitviewer, выполненную на JavaScript. Jitviewer представляет собой для визуализации процесса преобразования Python-кода в ассемблерный JIT-компилятором, встроенным в PyPy - реализацию интерпретатора питона на питоне".
т.е все их оптимизации, это написание более быстро sprintf...
А чего в этом плохого? Лучше быстрее, чем медленнее. Хотя, конечно, это моё субьективное мнение. Мало ли, вдруг за последние годы ценности изменились, и высокая скорость считается пороком.
Лол, в C++0x можно сделать sprintf на шаблонах, будет ещё быстрее. А вообще если оно специализирует каждый конкретный вызов sprintf, надо учесть затраты на собственно компиляцию, и ещё интересно сколько он жрёт памяти.Но вообще, направление правильное, т.к. нет великого зла - виртуальной машины.
А куда она делась? Она же внизу лежит, в интерпретаторе самого pypy...
> Разработчики проекта PyPy, в рамках которого развивается _реализация_ _языка_ _Python_ _со_ _статической_ _типизацией_э... ничего не порвалось?
Всё правильно делают. Динамическая типизация не нужна.
попробую поставить вопрос иначе. Где там статическая типизация?
Нигде. Автор новости просто перепутал. Наверное, с Cython. Там статическая типизация есть. Впрочем, динамическую тоже вроде бы никто не выбрасывал.
> Впрочем, динамическую тоже вроде бы никто не выбрасывал.В новости все верно написано. Как вы собрались динамическую типизацию компилировать в JIT-е ?
Так же, как компилируют полиморфизм в плюсах и прочих языках, где оный используется, когда статической типизации не хватает, а признаться в этом стыдно.
> попробую поставить вопрос иначе. Где там статическая типизация?В PyPy используется диалект RPython (Restricted Python), который поддерживает только статические типы и не допускает менять тип уже определенной переменной.
http://codespeak.net/pypy/dist/pypy/doc/coding-guide.html#ou...
"Unlike standard Python, RPython is statically typed, to allow efficient compilation"
> В PyPy используется диалект RPython (Restricted Python), который поддерживает только статические типыпонимаешь ли.. это не статическая типизация, а оптимизация для JITа.
> попробую поставить вопрос иначе. Где там статическая типизация?В диалекте RPython.
я тоже хочу знать что из себя представляет статическая типизация в Python, просто приведите пример кода и всё, больше ничего не нужно