Слэшдот пишет, что инжинеры из Гугла стартовали новый проект Unladen Swallow, в котором интерпретатор питона будет заменён JIT-компилятором на базе LLVM, за счёт чего планируется ускорить работу программ на Python в 5 раз. Исходный код уже доступен и первая версия версия уже на 15-25% быстрее стандартной имплементации CPython.
К> Слэшдот пишет, что инжинеры из Гугла стартовали новый проект Unladen Swallow, в котором интерпретатор питона будет заменён JIT-компилятором на базе LLVM, за счёт чего планируется ускорить работу программ на Python в 5 раз. Исходный код уже доступен и первая версия версия уже на 15-25% быстрее стандартной имплементации CPython.
— понижение прожорливости до памяти, в отдельных местах доходит до 930% по сравнению с Q2
— повышение производительности на отдельных мерилках доходит до 70%
— пройдены тесты на совместимость с:
Python regression test suite
2to3
Cheetah
cvs2svn Django
Nose NumPy
PyCrypto
pyOpenSSL
PyXML
Setuptools SQLAlchemy
SWIG
SymPy Twisted
ZODB
разработчики огорчают тем что:
— у них есть возможность, но нет времени на то, чтобы еще круче оптимизировать производительность
— по сравнению с cpython 2.6.1 прожорливость до памяти составляет 2-3 раза. обещают пофиксить к Q4.
Тесты производительности и более подробная информация тут.
Совершенно согласен с озвученным где-то мнением, что с выходом Q4, эта радость либо вольется в каноническую ветку, либо составит ей весьма нехилую конкуренцию. Короче, остается только ждать, надеяться и верить
Здравствуйте, mkizub, Вы писали:
M>Там нечего компилировать. В LLVM, в куда угодно. Если доступ к полю или методу идёт через поиск в хэщ-таблице, если в любой момент добавляются или изменяются поля, методы и способ доступа к ним — компилировать просто нечего.
RTFM — "Self", "TracingMonkey".
Здравствуйте, D. Mon, Вы писали:
>>compatibility with the vast array of C extension modules in production. DM>Я правильно понимаю, что для этого придется сборщик мусора оставить старым, а значит ни скорость, ни избавление от GIL им не грозят?
Возможно совмещённая схема. Т.е. C-шный код работает с refcount'ером, а нативный питоновский — с нормальным GC.
Там нечего компилировать. В LLVM, в куда угодно. Если доступ к полю или методу идёт через поиск в хэщ-таблице, если в любой момент добавляются или изменяются поля, методы и способ доступа к ним — компилировать просто нечего.
Питон неплох, но слухи об его ускорении сильно преувеличены. процентов 20-80 вполне допустимо. остальное — басни для тех, кто не знает, чем отличается интерпретатор от компилятора.
А вот ускорить Питон код в 15 раз можно уже сейчас — использовать Boo. Перешел на него с Питона и рад, как слон после спаривания, ибо код уменьшился на 25%, а скорость поразительно выросла (компилятор он и есть).
Для тех, кто не боится необкатанных языков, есть еще сильный питонообразный вариант — Cobra (http://cobra-language.org/). Еще быстрее и короче..
Здравствуйте, D. Mon, Вы писали:
DM>А есть ли у них соображения почему оно должно получиться сильно быстрее IronPython при сходной архитектуре?
По поводу производительности не скажу, но вот почему не IronPython:
Ultimately, the reason for working off of CPython is compatibility: compatibility with pure-Python code, and also compatibility with the vast array of C extension modules in production.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, Mr.Cat, Вы писали:
MC>>Я правильно понял, что Гвидо нет в списке разработчиков?
К>Кстати да... К>Одна рука не знает, что делает другая, в Гугле?
Здравствуйте, achmed, Вы писали:
A>Здравствуйте, Курилка, Вы писали:
К>>Здравствуйте, Mr.Cat, Вы писали:
MC>>>Я правильно понял, что Гвидо нет в списке разработчиков?
К>>Кстати да... К>>Одна рука не знает, что делает другая, в Гугле?
A>Вроде собираются все в одну ветку слить потом?
Ну патчи-то они пишут что отправляют, но сотрудники вроде одной конторы
Здравствуйте, D. Mon, Вы писали:
DM>А есть ли у них соображения почему оно должно получиться сильно быстрее IronPython при сходной архитектуре?
Наверно потому, что тот же, psyco на многих задачах гораздо шустрее чем IronPython.
Вообще если бы создатели psyco и PyPy пошли тем же путем которым хотят идти гугловцы, то думаю уже год — полтора назад у нас был бы на порядок более шустрый питон.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, D. Mon, Вы писали:
DM>>А есть ли у них соображения почему оно должно получиться сильно быстрее IronPython при сходной архитектуре?
FR>Наверно потому, что тот же, psyco на многих задачах гораздо шустрее чем IronPython.
А про псико вот что они пишут:
Psyco's claimed benefits of 100x speed-up on algorithmic code is rarely seen in real applications. It can certainly be used to optimize hotspots that fit Psyco's profile, but in examining the performance of some Google applications that use Psyco, we found that they see only a ~10% improvement in overall CPU usage. While that might be a valuable savings for some applications, it's not 100x, nor even the 2-4x low-end estimate that I've seen in the Psyco docs.
Здравствуйте, Курилка, Вы писали:
К>А про псико вот что они пишут: К>
К>Psyco's claimed benefits of 100x speed-up on algorithmic code is rarely seen in real applications. It can certainly be used to optimize hotspots that fit Psyco's profile, but in examining the performance of some Google applications that use Psyco, we found that they see only a ~10% improvement in overall CPU usage. While that might be a valuable savings for some applications, it's not 100x, nor even the 2-4x low-end estimate that I've seen in the Psyco docs.
Сильно зависит от задач, у меня реально на некторых было даже замедление.
Но на наших типичных задачах (логика казуальных игр) стабильно двух-трех кратное ускорение было.
Здравствуйте, FR, Вы писали:
FR>Сильно зависит от задач, у меня реально на некторых было даже замедление. FR>Но на наших типичных задачах (логика казуальных игр) стабильно двух-трех кратное ускорение было.
Здравствуйте, mkizub, Вы писали: M>Там нечего компилировать. В LLVM, в куда угодно. Если доступ к полю или методу идёт через поиск в хэщ-таблице, если в любой момент добавляются или изменяются поля, методы и способ доступа к ним — компилировать просто нечего.
Возможно, они будут оптимизировать как раз те случаи, когда явной работы с хеш-таблицей и добавления свойств в любой момент нет. Ну или что-то другое, но тоже выборочно. Конечно, нельзя оптимизировать все и вся — но можно оптимизировать то, что является узким местом в большинстве случаев.
Здравствуйте, Курилка, Вы писали:
К>А про псико вот что они пишут: К>
К>Psyco's claimed benefits of 100x speed-up on algorithmic code is rarely seen in real applications. It can certainly be used to optimize hotspots that fit Psyco's profile, but in examining the performance of some Google applications that use Psyco, we found that they see only a ~10% improvement in overall CPU usage. While that might be a valuable savings for some applications, it's not 100x, nor even the 2-4x low-end estimate that I've seen in the Psyco docs.
Кстати они это говорят своим прямым конкурентам и авторам psyco
Здравствуйте, Курилка, Вы писали:
К>Ну видать у вас с гуглом немного разные задачи
Возможно они не сильно старались, часто прямая прикрутка psyco мало что дает, все таки это не совсем полноценный jit, вот если немного повозится с настройками и внести небольшие правки в код можно и существенный выигрыш получить.
Здравствуйте, mkizub, Вы писали:
M>Там нечего компилировать. В LLVM, в куда угодно. Если доступ к полю или методу идёт через поиск в хэщ-таблице, если в любой момент добавляются или изменяются поля, методы и способ доступа к ним — компилировать просто нечего.
Здравствуйте, FR, Вы писали:
FR>Возможно они не сильно старались, часто прямая прикрутка psyco мало что дает, все таки это не совсем полноценный jit, вот если немного повозится с настройками и внести небольшие правки в код можно и существенный выигрыш получить.
Ну за них тут ничего сказать не могу
А по поводу правок, не может привести пример? И на обычном питоне эти правки не дают разницы?
DM> >compatibility with the vast array of C extension modules in production.
DM> Я правильно понимаю, что для этого придется сборщик мусора оставить старым, а значит ни скорость, ни избавление от GIL им не грозят?
В далекоидущих планах у них избавление от GIL. Не знаю, правда, как
Здравствуйте, mkizub, Вы писали:
M>Здравствуйте, Курилка, Вы писали:
M>Там нечего компилировать. В LLVM, в куда угодно. Если доступ к полю или методу идёт через поиск в хэщ-таблице, если в любой момент добавляются или изменяются поля, методы и способ доступа к ним — компилировать просто нечего.
На вкскидку — пусть есть цикл (Ц), который вызывет метод (F). Ясное дело, через хеш-таблицу.
methods=hash<id, (*F)()>
for(many-many-cycles) {
f = methods[id]
f()
}
Теперь мы хотим ускориться — убрать хеш. Возьмем и закешируем адрес вызываемой функции:
methods=hash<id, (*F)()>
f = methods[id]
for(many-many-cycles) {
f()
}
Понятно, что метод может поменяться — это же питон Чтоб не пролететь, рядом с методом будем хранить некий монотонный идентификатор (например таймстамп).
methods=hash<id, *F> // F - теперь пара <(*F)(), ts>
f = methods[id]
cachedTs = f.ts
for(many-many-cycles) {
if (f.ts != cachedTs) {
f = methods[id]
cachedTs = f.ts
}
f()
}
При изменении методов объекта (при изменении хеша) меняется и ts сопоставленный с этой функцией.
Получаем вместо хождения по хешам переход и проверку. Думаю что будет быстрее.
Вроде про что-то такой писал Joel после его наездов на Ruby (он еще ссылался на StrongTalk).
ЗЫ Писал навскидку, знающие люди, я надеюсь поправят если чего не так.
Здравствуйте, ettcat, Вы писали:
M>>Там нечего компилировать. В LLVM, в куда угодно. Если доступ к полю или методу идёт через поиск в хэщ-таблице, если в любой момент добавляются или изменяются поля, методы и способ доступа к ним — компилировать просто нечего.
E>На вкскидку — пусть есть цикл (Ц), который вызывет метод (F). Ясное дело, через хеш-таблицу. E>Теперь мы хотим ускориться — убрать хеш. Возьмем и закешируем адрес вызываемой функции: E>Получаем вместо хождения по хешам переход и проверку. Думаю что будет быстрее.
Это, кажется, впервые было сделано в Self (язык такой Sun-ом разрабатывался, сильно объектный). А может в Smalltalk-е.
В яве тоже следы от этого есть. В инструкции для вызова метода интерфейса специально (в байткоде) выделено место под этот закэшированный адрес.
Явовский интерпретатор находит метод интерфейса, патчит байткод идентификатором этого метода, и в следующий раз просто проверяет валидность найденного в предыдущий раз метода.
К компиляции в LLVM, как ты понимаешь, это отношения не имеет. Но, разумеется, ускоряет.
А шо, в питоне этого ещё не сделали?! Ну тогда конечно, я рад за питон, что у него это наконец появится. Шутка. Я не верю, что этого там ещё не сделали.
Здравствуйте, mkizub, Вы писали:
M>Явовский интерпретатор находит метод интерфейса, патчит байткод идентификатором этого метода, и в следующий раз просто проверяет валидность найденного в предыдущий раз метода. M>К компиляции в LLVM, как ты понимаешь, это отношения не имеет. Но, разумеется, ускоряет.
Почему это "не относится"??? Вся LLVM началась с работ по апгрейду процессов без их остановки.
Собственно, в одном проекте JVM переписывается под LLVM.
M>А шо, в питоне этого ещё не сделали?! Ну тогда конечно, я рад за питон, что у него это наконец появится. Шутка. Я не верю, что этого там ещё не сделали.
Нет, не сделали. Питон — это чистый интерпретатор.
Здравствуйте, ettcat, Вы писали:
E>Понятно, что метод может поменяться — это же питон Чтоб не пролететь, рядом с методом будем хранить некий монотонный идентификатор (например таймстамп).
Гораздо проще заблокировать исполнение кода метода (поставить защиту на изменяемый участок памяти), поменять код пока его гарантированно никто не выполняет, а потом дальше дать работать.
Здравствуйте, Cyberax, Вы писали:
M>>К компиляции в LLVM, как ты понимаешь, это отношения не имеет. Но, разумеется, ускоряет. C>Почему это "не относится"??? Вся LLVM началась с работ по апгрейду процессов без их остановки.
Потому, что это техника ускорения поиска динамического метода через кэширование предыдущего результата.
А LLVM это компиляция в нэйтивный код.
Они друг к другу отношения не имеют.
M>>А шо, в питоне этого ещё не сделали?! Ну тогда конечно, я рад за питон, что у него это наконец появится. Шутка. Я не верю, что этого там ещё не сделали. C>Нет, не сделали. Питон — это чистый интерпретатор.
Да хоть грязный. Оптимизировать интерпретацию это не мешает.
Кстати, тут давали название реализации питона, где это сделано. Похоже, этот ответ помер в связи с глюками RSDN-а. Вот его копия
От: D. Mon
Здравствуйте, ettcat, Вы писали:
E>Теперь мы хотим ускориться — убрать хеш. Возьмем и закешируем адрес вызываемой функции:
В IronPython (с его DLR) так сделано, даже более того — оно еще и компиляется. Однако скорость по-прежнему невысока. Еще идеи?
Здравствуйте, Курилка, Вы писали:
К>А по поводу правок, не может привести пример? И на обычном питоне эти правки не дают разницы?
Боюсь сейчас так просто не смогу привести, в настоящее время у меня только C++
А так в основном сводилось к разбивке некторых больших функций, и переводу небольшой части алгоритмов
только на целые числа, что без psyco замедляло работу.
Здравствуйте, Курилка, Вы писали:
К>Слэшдот пишет, что инжинеры из Гугла стартовали новый проект Unladen Swallow, в котором интерпретатор питона будет заменён JIT-компилятором на базе LLVM, за счёт чего планируется ускорить работу программ на Python в 5 раз. Исходный код уже доступен и первая версия версия уже на 15-25% быстрее стандартной имплементации CPython.
Вышла редакция Release2009Q2 — ускорение не в разы, но имеется.
Re[2]: [Python] можно сейчас ускорить в 15 раз уже
Здравствуйте, _Claus_, Вы писали:
_C_>Для тех, кто не боится необкатанных языков, есть еще сильный питонообразный вариант — Cobra (http://cobra-language.org/). Еще быстрее и короче..
Right now, if you want software contracts in your language, how can you get them? The answer is to use Eiffel or D. What if you want static and dynamic binding? Use Objective-C or Boo. What if you want expressiveness and quick coding? Use Python, Ruby or Smalltalk. What if you want runtime performance? Use C#, Java, C++, etc. What if you want first class language support for unit tests? Use D.
But what if you want all of those?
Ребятишки не знают про http://nemerle.org
Там есть все перечисленное (не всегда в самом языке ибо макры рулят) плюс много чего еще.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: [Python] можно сейчас ускорить в 15 раз уже
Здравствуйте, WolfHound, Вы писали: WH>Ребятишки не знают про http://nemerle.org WH>Там есть все перечисленное (не всегда в самом языке ибо макры рулят) плюс много чего еще.
В свою очередь nemerle — это такая типизированная scheme
Re[4]: [Python] можно сейчас ускорить в 15 раз уже
Здравствуйте, Mr.Cat, Вы писали:
MC>В свою очередь nemerle — это такая типизированная scheme
Вот именно что типизированная. А это дает проверки во время компиляции и гораздо более широкие возможности по оптимизации.
Более развитая система типов (например зависимые типы) позволит делать и то и друге гораздо лучше.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[3]: [Python] можно сейчас ускорить в 15 раз уже
Здравствуйте, WolfHound, Вы писали:
WH>Ребятишки не знают про http://nemerle.org WH>Там есть все перечисленное (не всегда в самом языке ибо макры рулят) плюс много чего еще.
Ты годом не ошибся?
Сейчас в моде пропагандировать Хаскель, мода не Немерли прошла
Re[5]: [Python] можно сейчас ускорить в 15 раз уже
Здравствуйте, WolfHound, Вы писали:
MC>>В свою очередь nemerle — это такая типизированная scheme WH>Вот именно что типизированная. А это дает проверки во время компиляции и гораздо более широкие возможности по оптимизации.
А эти отпимизации реализованы в компиляторе, или пока нет?
Есть ли где их список или хотя бы описание "вот это можно будет соптимиздить, и тут и тут…"?
Help will always be given at Hogwarts to those who ask for it.
Здравствуйте, Курилка, Вы писали:
К>Слэшдот пишет, что инжинеры из Гугла стартовали новый проект Unladen Swallow, в котором интерпретатор питона будет заменён JIT-компилятором на базе LLVM, за счёт чего планируется ускорить работу программ на Python в 5 раз. Исходный код уже доступен и первая версия версия уже на 15-25% быстрее стандартной имплементации CPython.
Да, теперь программы на питоне будут в 5 раз быстрее сыпать эксепшенами в логи.
)
