Здравствуйте, FR, Вы писали:
FR>Возможно они не сильно старались, часто прямая прикрутка psyco мало что дает, все таки это не совсем полноценный jit, вот если немного повозится с настройками и внести небольшие правки в код можно и существенный выигрыш получить.
Ну за них тут ничего сказать не могу
А по поводу правок, не может привести пример? И на обычном питоне эти правки не дают разницы?
DM> >compatibility with the vast array of C extension modules in production.
DM> Я правильно понимаю, что для этого придется сборщик мусора оставить старым, а значит ни скорость, ни избавление от GIL им не грозят?
В далекоидущих планах у них избавление от GIL. Не знаю, правда, как
Питон неплох, но слухи об его ускорении сильно преувеличены. процентов 20-80 вполне допустимо. остальное — басни для тех, кто не знает, чем отличается интерпретатор от компилятора.
А вот ускорить Питон код в 15 раз можно уже сейчас — использовать Boo. Перешел на него с Питона и рад, как слон после спаривания, ибо код уменьшился на 25%, а скорость поразительно выросла (компилятор он и есть).
Для тех, кто не боится необкатанных языков, есть еще сильный питонообразный вариант — Cobra (http://cobra-language.org/). Еще быстрее и короче..
Re[2]: [Python] можно сейчас ускорить в 15 раз уже
Здравствуйте, 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.
— понижение прожорливости до памяти, в отдельных местах доходит до 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, эта радость либо вольется в каноническую ветку, либо составит ей весьма нехилую конкуренцию. Короче, остается только ждать, надеяться и верить
Здравствуйте, Курилка, Вы писали:
К>Слэшдот пишет, что инжинеры из Гугла стартовали новый проект Unladen Swallow, в котором интерпретатор питона будет заменён JIT-компилятором на базе LLVM, за счёт чего планируется ускорить работу программ на Python в 5 раз. Исходный код уже доступен и первая версия версия уже на 15-25% быстрее стандартной имплементации CPython.
Да, теперь программы на питоне будут в 5 раз быстрее сыпать эксепшенами в логи.