То, что Unladen Swallow умер — очень печально.
Было бы здорово иметь лучшую производительность бесплатно, не прилагая никаких усилий.
Но так ли эта скорость нужна?
Позвольте уточнить.
Мои периодические опросы показывают, что мало кто из питонщиков занимается профилилованием кода.
Я имею в виду profile/cProfile и последующий анализ.
Зато часто говорят о скорости, о том что питон медленный и не мешало бы ему стать быстрее.
Тем не менее ответственно заявляю: увеличение производительности без предварительного анализа невозможно в принципе. Если вы не запускаете профайлер для вашего проекта — не говорите ни слова о скорости. Не смешите людей.
Далее. Иногда (не слишком часто) проблема быстродействия возникала на проектах, с которыми я имел дело. Чаще всего она решалась подбором правильных алгоритмов и структур данных.
Именно так: если у вас что-то тормозит — скорее всего ошибка в подходе. Правильно написанная программа редко упирается в недостаточную производительность самого Питона — обычно проблема заключается в кривых руках программиста.
Очень редко получается такая ситуация, что алгоритмически все идеально, но скорости все еще не хватает. Для этого стоит изучить Python C Extensions. Оптимизация нескольких (как правило их можно пересчитать по пальцам) узких мест способна закрыть проблему раз и навсегда.
И если перечисленное не помогло (а обычно этих действий вполне достаточно) — тогда да, вам нужен более быстрый Питон. Но не ранее.
Скорость интерпретатора (как и набивший оскомину GIL) являются великолепными отмазками для недостаточно квалифицированных разработчиков. Они не понимают текущее положение вещей, а значит и не могут его существенно улучшить. Зато имеют отличный повод сказать: «Вот если бы не GIL — моя программа летала бы со скоростью света!» Но ведь это не правда. Как правило проблема кроется в другом. Приемлемую скорость можно получить и на имеющемся инструменте. Более того, более быстрый питон мало бы помог: лучший способ ускорения кода с квадратичной сложностью — приведение этой сложности к логарифмической. И так далее.
Какое бурное обсуждение!
А я всегда считал, что бесполезно мешать программисту выстрелить себе в ногу — если он этого так жаждет.
Неблагодарное это дело. Разработчики — люди изобретательные. Они все равно сумеют обойти все ограничения и с наслаждением разрядят ружжо в свою конечность.
У меня по примерно той же причине винт умер весной на windows xp (toshiba A100) (спецы из сервисного головой качали, но таки заменили). Что-то пошло вразнос. Парковался - и распарковывался постоянно. И сдох в конце концов. Так что теперь? Windows - rules, *nix must die? Или наоборот?
Или просто от багов никто не застрахован? Выбирайте себе по вкусу.
Извините, но это для кого угодно - но только не для разработчиков игр.
Для каждой игры существует масса требований по исполнению 3Д моделей.
Обоснованных технологией. И чужие модельки без адаптации ничего не стоят.
А процесс адаптации такой, что легче рисовать все заново.
А так - да!!!. Красивый маркетинговый ход.
Было бы здорово иметь лучшую производительность бесплатно, не прилагая никаких усилий.
Но так ли эта скорость нужна?
Позвольте уточнить.
Мои периодические опросы показывают, что мало кто из питонщиков занимается профилилованием кода.
Я имею в виду profile/cProfile и последующий анализ.
Зато часто говорят о скорости, о том что питон медленный и не мешало бы ему стать быстрее.
Тем не менее ответственно заявляю: увеличение производительности без предварительного анализа невозможно в принципе. Если вы не запускаете профайлер для вашего проекта — не говорите ни слова о скорости. Не смешите людей.
Далее. Иногда (не слишком часто) проблема быстродействия возникала на проектах, с которыми я имел дело. Чаще всего она решалась подбором правильных алгоритмов и структур данных.
Именно так: если у вас что-то тормозит — скорее всего ошибка в подходе. Правильно написанная программа редко упирается в недостаточную производительность самого Питона — обычно проблема заключается в кривых руках программиста.
Очень редко получается такая ситуация, что алгоритмически все идеально, но скорости все еще не хватает. Для этого стоит изучить Python C Extensions. Оптимизация нескольких (как правило их можно пересчитать по пальцам) узких мест способна закрыть проблему раз и навсегда.
И если перечисленное не помогло (а обычно этих действий вполне достаточно) — тогда да, вам нужен более быстрый Питон. Но не ранее.
Скорость интерпретатора (как и набивший оскомину GIL) являются великолепными отмазками для недостаточно квалифицированных разработчиков. Они не понимают текущее положение вещей, а значит и не могут его существенно улучшить. Зато имеют отличный повод сказать: «Вот если бы не GIL — моя программа летала бы со скоростью света!» Но ведь это не правда. Как правило проблема кроется в другом. Приемлемую скорость можно получить и на имеющемся инструменте. Более того, более быстрый питон мало бы помог: лучший способ ускорения кода с квадратичной сложностью — приведение этой сложности к логарифмической. И так далее.
Резюмируя: плохому танцору ноги мешают.
А я всегда считал, что бесполезно мешать программисту выстрелить себе в ногу — если он этого так жаждет.
Неблагодарное это дело. Разработчики — люди изобретательные. Они все равно сумеют обойти все ограничения и с наслаждением разрядят ружжо в свою конечность.
Или просто от багов никто не застрахован? Выбирайте себе по вкусу.
Для каждой игры существует масса требований по исполнению 3Д моделей.
Обоснованных технологией. И чужие модельки без адаптации ничего не стоят.
А процесс адаптации такой, что легче рисовать все заново.
А так - да!!!. Красивый маркетинговый ход.