1.1, usp (?), 00:20, 13/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Как может Python обогнать Си. Неужели Си реализация настолько крива изнутри?
| |
|
2.17, Damon (??), 10:56, 13/03/2010 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Как может Python обогнать Си. Неужели Си реализация настолько крива изнутри?
У самого сначала такая реакция была, потом внимательнее перечитал и все встало на свои места.
>> появление JIT-компилятора, позволяющего ... обогнать по производительности реализацию Python на языке Си
Далее:
>> JIT работает значительно быстрее интерпретации байткода
Ну и окончательно из wiki (http://ru.wikipedia.org/wiki/JIT):
>> Just-in-time compilation (JIT) (также известна как dynamic translation) — компиляция «на лету» — это технология увеличения производительности программных систем, использующих байт-код, путём трансляции байт-кода в машинный код непосредственно во время работы программы.
Таким образом подразумевается, что C'шный вариант -- тупо _интерпретирует_ байткод, PyPy же, сначала _компилирует_ байткод, в нативный код для платформы на которой работает, а потом выполняет.
| |
|
3.22, Mna (??), 16:07, 13/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Таким образом подразумевается, что C'шный вариант -- тупо _интерпретирует_ байткод,
"байт-код С" нет такого, оно компилируется в asm/машинные коды!
| |
|
4.23, Damon (??), 16:36, 13/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
> "байт-код С" нет такого, оно компилируется в asm/машинные коды!
Вы несомненно правы, насчет "байт-код Це", такого точно нет, хотя может где-нить и у кого-нить завалялся, но я про такой не слышал... Зато Python точно компилирует исходники в промежуточный байт-код, который CPython потом _интерпретирует_.
Вы вообще, знаете, чем интерпретатор от компилятора отличается, кроме букв в названии? Вот здесь доходчиво и на "Великом и Могучем", правда кратко, про Python описано -- http://adw0rd.ru/2009/python-howto-work/...
| |
|
|
2.30, User294 (ok), 07:14, 14/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Как может Python обогнать Си. Неужели Си реализация настолько крива изнутри?
Дык, JIT vs интерпретатор, однако. Ессно JIT быстрее тупой интерпретации. Тупая интерпретация - самый тормозной вариант из всех возможных. Обычный классический питон - тупорылый тормозной интерпретер.
| |
|
1.8, минона (?), 02:37, 13/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
ну скорее бы уже вышел PyPyPy
а за ним - PyPyPyPy
сразу будет чем занять 4-я ядра
| |
|
2.9, we7594 (?), 06:54, 13/03/2010 [^] [^^] [^^^] [ответить]
| –8 +/– |
Во-первых, это старая шутка.
А во-вторых, старые языки надо давно уже закопать, а весь юзерспейс писать на нормальных ЯП: на джаве или питоне.
| |
|
3.18, Coder (?), 12:50, 13/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
Тогда уж и процессоры пора выпускать, которые сами будут понимать несколько высокоуровневых языков и компилировать код самостоятельно
| |
|
|
5.26, User294 (ok), 07:00, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
Что самое интересное:
1) Оно не документировано. Прикиньте? Вот так захотите вы написать что-то юзающее его и обломитесь если NDA подписывать вломак :)
2) Оно ориентировано сугубо на яву...
3) Оно ускоряет только некоторые операции
4) И все-равно яве это не сильно помогает в конечном итоге.
| |
|
|
3.27, User294 (ok), 07:05, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А во-вторых, старые языки надо давно уже закопать, а весь юзерспейс писать
>на нормальных ЯП: на джаве или питоне.
Это чтобы четырехъдерники начали тормозить как первые пеньки и гигазы оперативки было чем занять вместо дисковых буферов? Сперва сделайте скорость работы этих тормозил не хуже прог на сях, а потом вещайте уже. А то монструозные тормозилки которые стартуют как проги для спекки грузящиеся с ленты и жрущие вагон ресурсов - юзеров не очень радуют и поэтому захват мира жабисты обещают нам наверное уже этак с ~десятилетие. А никакого захвата мира все не случается и не случается. Прямо как конец света который все отодвигается и отодвигается :)
| |
3.36, Stocker (?), 18:23, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
+1, гугл тоже так думает. Только тут все лают на джаву, но при этом обожают питон без jit'а.
| |
|
2.10, Alen (??), 06:54, 13/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
И не говори, что то эти халтурщики заметно отстают от ядроклепателей из интела, видимо пора переходить на новый уровень, написать на питоне циклоразмножатель PyPyPy.......n*Py
:)
| |
|
3.16, Damon (??), 10:49, 13/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
> ... PyPyPy.......n*Py
n*Py = Py + Py + Py + ... + Py
Тогда уж -- Py^n ;-)
| |
|
4.28, User294 (ok), 07:05, 14/03/2010 [^] [^^] [^^^] [ответить]
| –1 +/– |
>n*Py = Py + Py + Py + ... + Py
А потом на месте процессора образуется черная дыра, когда рекурсия уйдет в бесконечность? oO
| |
|
5.34, аноним (?), 16:49, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>А потом на месте процессора образуется черная дыра, когда рекурсия уйдет в
>бесконечность? oO
кстати, о черных дырах, квантово-гравитационных компьютерных механизмах, вложенных вселенных, Пенроузе и Ли Смолине тут:
http://lj.rossia.org/users/tiphareth/1215094.html
так что, как бы я не любил питона, но за Py^n будущее :)
| |
|
|
3.19, Coder (?), 12:54, 13/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
>И не говори, что то эти халтурщики заметно отстают от ядроклепателей из
>интела, видимо пора переходить на новый уровень, написать на питоне циклоразмножатель
>PyPyPy.......n*Py
Не просто циклоразмонжитель, а создатель высокоуровневых языков на лету с компиляторами
| |
|
|
1.15, anonymous (??), 10:33, 13/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
"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, меньше памяти"
| |
|
2.37, аноним (?), 00:38, 15/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
Хм, это что, генетическая проблема любого JIT? Объем кода ограничен, с какого хрена JIT занимает больше памяти, чем занял бы соответствующий нативный бинарник? Или все программы на питоне из eval'ов строк состоят, на которые надо каждый раз новый код генерить?
| |
|
1.24, pro100master (ok), 18:59, 13/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
посмешили результаты:
cnt = 10 * 1000 * 1000
for _ in xrange(cnt):
i = i + 1
примерно в 10 раз медленнее gcc. Уверен, тут будет, как со сторонниками джавы :)))
| |
|
2.29, User294 (ok), 07:11, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
gcc в таком случае зачастую оптимизит и сразу делает возврат нужного значения. Удачи сделать его при этом, ага :). Пока супер-пупер jit движки и прочие мегамонстры только запустсятся, у gcc результат уже 20 раз будет на выходе :)
| |
|
1.25, Аноним (-), 20:49, 13/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
потестил два варианта, на python2.6, pupy1.2, и fpc2.4.0
def 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
39
real 0m37.146s
user 0m37.130s
sys 0m0.000s
$ time ./pascal_example
39
real 0m6.859s
user 0m6.830s
sys 0m0.010s
$ time ./bin/pypy python_example.py
39
real 0m5.534s
user 0m5.520s
sys 0m0.010s
)))) Забавно))))
| |
|
2.31, Salvator (?), 12:07, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
попробуйте в питоновом коде использовать xrange вместо range. по идее, еще быстрее должно работать)
| |
2.38, Аноним (-), 08:40, 15/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
У меня тот же код с Cpython отрабатывает за 33,591 сек, а с
import psyco
psyco.full()
за 4,025 сек. :)
| |
|
1.33, аноним (?), 15:57, 14/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
И толку от этого pypy? Какая у него совместимость с python 25,26,31? Его можно использовать как drop-in заменитель нормального питона? Почему jit вообще разработали как сторонний проект?
| |
|
2.35, jbo (??), 17:31, 14/03/2010 [^] [^^] [^^^] [ответить]
| +/– |
пока только поигратся
pypy непонимает С API тоесть про PIL, mysql можно забыть (можно конечто через костыль rpyc, но при этом теряем скорость)
нет x86_64
| |
|
1.39, Mna (??), 07:53, 26/03/2010 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
У меня тот же код занял времени:
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
39
real 0m22.907s
user 0m22.809s
sys 0m0.018s
[Cython]$ time python -c "import xpy"
39
real 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)
39
real 0m2.615s
user 0m2.592s
sys 0m0.010s
[Cython]$ time python -c "import xpy2"
39
real 0m1.426s
user 0m1.388s
sys 0m0.009s
Но надо сказать, что PyPy работает только как 32-битная программа, что конечно ...не так прекрасно.
Другой его минус - что он (PyPy) застрял на версии питона 2.5.2 (когда 2.6.4 на дворе)
| |
|