Слэшдот пишет, что инжинеры из Гугла стартовали новый проект Unladen Swallow, в котором интерпретатор питона будет заменён JIT-компилятором на базе LLVM, за счёт чего планируется ускорить работу программ на Python в 5 раз. Исходный код уже доступен и первая версия версия уже на 15-25% быстрее стандартной имплементации CPython.
К> Слэшдот пишет, что инжинеры из Гугла стартовали новый проект Unladen Swallow, в котором интерпретатор питона будет заменён JIT-компилятором на базе LLVM, за счёт чего планируется ускорить работу программ на Python в 5 раз. Исходный код уже доступен и первая версия версия уже на 15-25% быстрее стандартной имплементации CPython.
Здравствуйте, 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, Вы писали:
>>compatibility with the vast array of C extension modules in production. DM>Я правильно понимаю, что для этого придется сборщик мусора оставить старым, а значит ни скорость, ни избавление от GIL им не грозят?
Возможно совмещённая схема. Т.е. C-шный код работает с refcount'ером, а нативный питоновский — с нормальным GC.
Здравствуйте, 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>Но на наших типичных задачах (логика казуальных игр) стабильно двух-трех кратное ускорение было.
Там нечего компилировать. В LLVM, в куда угодно. Если доступ к полю или методу идёт через поиск в хэщ-таблице, если в любой момент добавляются или изменяются поля, методы и способ доступа к ним — компилировать просто нечего.
Здравствуйте, 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, в куда угодно. Если доступ к полю или методу идёт через поиск в хэщ-таблице, если в любой момент добавляются или изменяются поля, методы и способ доступа к ним — компилировать просто нечего.
Здравствуйте, mkizub, Вы писали:
M>Там нечего компилировать. В LLVM, в куда угодно. Если доступ к полю или методу идёт через поиск в хэщ-таблице, если в любой момент добавляются или изменяются поля, методы и способ доступа к ним — компилировать просто нечего.
RTFM — "Self", "TracingMonkey".
