Увидел свет (http://morepypy.blogspot.com/2010/03/introducing-pypy-12-rel...) релиз PyPy 1.2 (http://pypy.org), интерпретатора Python 2.5 написанного на языке Python. Главное улучшение новой версии - появление JIT-компилятора, позволяющего при выполнении некоторых операций обогнать по производительности реализацию Python на языке Си (CPython), в то время как без использования JIT, CPython обгоняет PyPy в 2-3 раза. По заявлению разработчиков PyPy еще не готов для промышленной эксплуатации, но уже значительно приблизился к этой отметке.
Кроме высокой скорости работы, PyPy потребляет (http://pypy.org/features.html), по сравнению с CPython, меньше памяти. В PyPy также поддерживается бесстековый (Stackless) режим работы, позволяющий добиться массового параллельного выполнения микро-нитей (micro-threads). Для выполнения кода к которому нет доверия реализован режим изолированного выполнения, отличающегося от sandbox в CPython полной поддержкой всех возможностей языка, без выделени...URL: http://morepypy.blogspot.com/2010/03/introducing-pypy-12-rel...
Новость: http://www.opennet.me/opennews/art.shtml?num=25782
Как может Python обогнать Си. Неужели Си реализация настолько крива изнутри?
Он умеет сам себя компилировать в машинный код.
>Как может Python обогнать Си. Неужели Си реализация настолько крива изнутри?У самого сначала такая реакция была, потом внимательнее перечитал и все встало на свои места.
>> появление JIT-компилятора, позволяющего ... обогнать по производительности реализацию Python на языке Си
Далее:
>> JIT работает значительно быстрее интерпретации байткодаНу и окончательно из wiki (http://ru.wikipedia.org/wiki/JIT):
>> Just-in-time compilation (JIT) (также известна как dynamic translation) — компиляция «на лету» — это технология увеличения производительности программных систем, использующих байт-код, путём трансляции байт-кода в машинный код непосредственно во время работы программы.Таким образом подразумевается, что C'шный вариант -- тупо _интерпретирует_ байткод, PyPy же, сначала _компилирует_ байткод, в нативный код для платформы на которой работает, а потом выполняет.
> Таким образом подразумевается, что C'шный вариант -- тупо _интерпретирует_ байткод,"байт-код С" нет такого, оно компилируется в asm/машинные коды!
> "байт-код С" нет такого, оно компилируется в asm/машинные коды!Вы несомненно правы, насчет "байт-код Це", такого точно нет, хотя может где-нить и у кого-нить завалялся, но я про такой не слышал... Зато Python точно компилирует исходники в промежуточный байт-код, который CPython потом _интерпретирует_.
Вы вообще, знаете, чем интерпретатор от компилятора отличается, кроме букв в названии? Вот здесь доходчиво и на "Великом и Могучем", правда кратко, про Python описано -- http://adw0rd.ru/2009/python-howto-work/...
>Как может Python обогнать Си. Неужели Си реализация настолько крива изнутри?Дык, JIT vs интерпретатор, однако. Ессно JIT быстрее тупой интерпретации. Тупая интерпретация - самый тормозной вариант из всех возможных. Обычный классический питон - тупорылый тормозной интерпретер.
ключевое слово 'некоторые операции'
Если все это кажется ненормальным, рекомендую ознакомиться с концепцией "Meta-circular evaluator" (интересно, как это по-русски называется): http://en.wikipedia.org/wiki/Meta-circular
ну скорее бы уже вышел PyPyPy
а за ним - PyPyPyPy
сразу будет чем занять 4-я ядра
Во-первых, это старая шутка.А во-вторых, старые языки надо давно уже закопать, а весь юзерспейс писать на нормальных ЯП: на джаве или питоне.
Тогда уж и процессоры пора выпускать, которые сами будут понимать несколько высокоуровневых языков и компилировать код самостоятельно
ARM Jazelle?
Что самое интересное:
1) Оно не документировано. Прикиньте? Вот так захотите вы написать что-то юзающее его и обломитесь если NDA подписывать вломак :)
2) Оно ориентировано сугубо на яву...
3) Оно ускоряет только некоторые операции
4) И все-равно яве это не сильно помогает в конечном итоге.
>А во-вторых, старые языки надо давно уже закопать, а весь юзерспейс писать
>на нормальных ЯП: на джаве или питоне.Это чтобы четырехъдерники начали тормозить как первые пеньки и гигазы оперативки было чем занять вместо дисковых буферов? Сперва сделайте скорость работы этих тормозил не хуже прог на сях, а потом вещайте уже. А то монструозные тормозилки которые стартуют как проги для спекки грузящиеся с ленты и жрущие вагон ресурсов - юзеров не очень радуют и поэтому захват мира жабисты обещают нам наверное уже этак с ~десятилетие. А никакого захвата мира все не случается и не случается. Прямо как конец света который все отодвигается и отодвигается :)
> нормальных ЯП: на джаве или питонеТолсто.
+1, гугл тоже так думает. Только тут все лают на джаву, но при этом обожают питон без jit'а.
И не говори, что то эти халтурщики заметно отстают от ядроклепателей из интела, видимо пора переходить на новый уровень, написать на питоне циклоразмножатель PyPyPy.......n*Py
:)
> ... PyPyPy.......n*Pyn*Py = Py + Py + Py + ... + Py
Тогда уж -- Py^n ;-)
>n*Py = Py + Py + Py + ... + PyА потом на месте процессора образуется черная дыра, когда рекурсия уйдет в бесконечность? oO
>А потом на месте процессора образуется черная дыра, когда рекурсия уйдет в
>бесконечность? oOкстати, о черных дырах, квантово-гравитационных компьютерных механизмах, вложенных вселенных, Пенроузе и Ли Смолине тут:
http://lj.rossia.org/users/tiphareth/1215094.html
так что, как бы я не любил питона, но за Py^n будущее :)
>И не говори, что то эти халтурщики заметно отстают от ядроклепателей из
>интела, видимо пора переходить на новый уровень, написать на питоне циклоразмножатель
>PyPyPy.......n*PyНе просто циклоразмонжитель, а создатель высокоуровневых языков на лету с компиляторами
"It is still memory-hungry. There is no limit on the amount of RAM that the assembler can consume; it is thus possible (although unlikely) that the assembler ends up using unreasonable amounts of memory."Это по ссылке. Автор новости творчески переосмыслил?
"Кроме высокой скорости работы, PyPy потребляет, по сравнению с CPython, меньше памяти"
Хм, это что, генетическая проблема любого JIT? Объем кода ограничен, с какого хрена JIT занимает больше памяти, чем занял бы соответствующий нативный бинарник? Или все программы на питоне из eval'ов строк состоят, на которые надо каждый раз новый код генерить?
посмешили результаты:
cnt = 10 * 1000 * 1000
for _ in xrange(cnt):
i = i + 1примерно в 10 раз медленнее gcc. Уверен, тут будет, как со сторонниками джавы :)))
gcc в таком случае зачастую оптимизит и сразу делает возврат нужного значения. Удачи сделать его при этом, ага :). Пока супер-пупер jit движки и прочие мегамонстры только запустсятся, у gcc результат уже 20 раз будет на выходе :)
потестил два варианта, на python2.6, pupy1.2, и fpc2.4.0def test():
r = 0
for i in range(0, 10000):
for j in range(0, 10000):
r = (r + (i * j) % 100) % 47
return r
print(test())
--------------
function test : integer;
var
r : integer = 0;
i, j : integer;
begin
for i:=0 to 10000 do
for j:=0 to 10000 do
r:=(r + (i*j) mod 100) mod 47;
test:=r;
end;
begin
writeln(test);
end.
-------------
На паскале компилил с опцией release.
Результаты:$ time python python_example.py
39real 0m37.146s
user 0m37.130s
sys 0m0.000s$ time ./pascal_example
39real 0m6.859s
user 0m6.830s
sys 0m0.010s$ time ./bin/pypy python_example.py
39real 0m5.534s
user 0m5.520s
sys 0m0.010s)))) Забавно))))
попробуйте в питоновом коде использовать xrange вместо range. по идее, еще быстрее должно работать)
У меня тот же код с Cpython отрабатывает за 33,591 сек, а сimport psyco
psyco.full()за 4,025 сек. :)
И толку от этого pypy? Какая у него совместимость с python 25,26,31? Его можно использовать как drop-in заменитель нормального питона? Почему jit вообще разработали как сторонний проект?
пока только поигратся
pypy непонимает С API тоесть про PIL, mysql можно забыть (можно конечто через костыль rpyc, но при этом теряем скорость)
нет x86_64
У меня тот же код занял времени:
Python - 22.9с
Cython - 13.2с (неоптимизорованный, т.е. без описанных типов)
PyPy - 2.6с
Cython - 1.4с (с описанными типами, добавлена строка: cdef int r,i,j)Unladen Swallow - нескомпилировался сам - требует построить на слишком новый LLVM (2.7)
Psyco - рабочих бинарников не было, а исходники отказались работать на 64 битах, и предложили перейти на PyPyСобственно, PyPy себя оправдал, хотя также работает только на 32 битах. Вобщем, можно рекомендовать его
использовать.В данном случае вычислений, быстрее Cython-а с описанными типами невозможно, поскольку код уже получился
самый оптимальный, видно по сгенерированному С-коду. Может для более сложного кода что-то и изменилось бы.
Но он требует описаний типов, что замедляет разработку, и не для каждого случая приемлемо, особенно если
PyPy ненамного медленнее.===
$ time python x-py.py
39real 0m22.907s
user 0m22.809s
sys 0m0.018s[Cython]$ time python -c "import xpy"
39real 0m13.264s
user 0m13.173s
sys 0m0.011s$ time ./pypy-1.2/bin/pypy x-py.py
./pypy-1.2/bin/pypy: /usr/lib/libcrypto.so.0.9.8: no version information available (required by ./pypy-1.2/bin/pypy)
./pypy-1.2/bin/pypy: /usr/lib/libssl.so.0.9.8: no version information available (required by ./pypy-1.2/bin/pypy)
39real 0m2.615s
user 0m2.592s
sys 0m0.010s[Cython]$ time python -c "import xpy2"
39real 0m1.426s
user 0m1.388s
sys 0m0.009sНо надо сказать, что PyPy работает только как 32-битная программа, что конечно ...не так прекрасно.
Другой его минус - что он (PyPy) застрял на версии питона 2.5.2 (когда 2.6.4 на дворе)