Комментарии 17
То, что Unladen Swallow умер — очень печально.
Было бы здорово иметь лучшую производительность бесплатно, не прилагая никаких усилий.
Но так ли эта скорость нужна?
Позвольте уточнить.
Мои периодические опросы показывают, что мало кто из питонщиков занимается профилилованием кода.
Я имею в виду profile/cProfile и последующий анализ.
Зато часто говорят о скорости, о том что питон медленный и не мешало бы ему стать быстрее.
Тем не менее ответственно заявляю: увеличение производительности без предварительного анализа невозможно в принципе. Если вы не запускаете профайлер для вашего проекта — не говорите ни слова о скорости. Не смешите людей.
Далее. Иногда (не слишком часто) проблема быстродействия возникала на проектах, с которыми я имел дело. Чаще всего она решалась подбором правильных алгоритмов и структур данных.
Именно так: если у вас что-то тормозит — скорее всего ошибка в подходе. Правильно написанная программа редко упирается в недостаточную производительность самого Питона — обычно проблема заключается в кривых руках программиста.
Очень редко получается такая ситуация, что алгоритмически все идеально, но скорости все еще не хватает. Для этого стоит изучить Python C Extensions. Оптимизация нескольких (как правило их можно пересчитать по пальцам) узких мест способна закрыть проблему раз и навсегда.
И если перечисленное не помогло (а обычно этих действий вполне достаточно) — тогда да, вам нужен более быстрый Питон. Но не ранее.
Скорость интерпретатора (как и набивший оскомину GIL) являются великолепными отмазками для недостаточно квалифицированных разработчиков. Они не понимают текущее положение вещей, а значит и не могут его существенно улучшить. Зато имеют отличный повод сказать: «Вот если бы не GIL — моя программа летала бы со скоростью света!» Но ведь это не правда. Как правило проблема кроется в другом. Приемлемую скорость можно получить и на имеющемся инструменте. Более того, более быстрый питон мало бы помог: лучший способ ускорения кода с квадратичной сложностью — приведение этой сложности к логарифмической. И так далее.
Резюмируя: плохому танцору ноги мешают.
Было бы здорово иметь лучшую производительность бесплатно, не прилагая никаких усилий.
Но так ли эта скорость нужна?
Позвольте уточнить.
Мои периодические опросы показывают, что мало кто из питонщиков занимается профилилованием кода.
Я имею в виду profile/cProfile и последующий анализ.
Зато часто говорят о скорости, о том что питон медленный и не мешало бы ему стать быстрее.
Тем не менее ответственно заявляю: увеличение производительности без предварительного анализа невозможно в принципе. Если вы не запускаете профайлер для вашего проекта — не говорите ни слова о скорости. Не смешите людей.
Далее. Иногда (не слишком часто) проблема быстродействия возникала на проектах, с которыми я имел дело. Чаще всего она решалась подбором правильных алгоритмов и структур данных.
Именно так: если у вас что-то тормозит — скорее всего ошибка в подходе. Правильно написанная программа редко упирается в недостаточную производительность самого Питона — обычно проблема заключается в кривых руках программиста.
Очень редко получается такая ситуация, что алгоритмически все идеально, но скорости все еще не хватает. Для этого стоит изучить Python C Extensions. Оптимизация нескольких (как правило их можно пересчитать по пальцам) узких мест способна закрыть проблему раз и навсегда.
И если перечисленное не помогло (а обычно этих действий вполне достаточно) — тогда да, вам нужен более быстрый Питон. Но не ранее.
Скорость интерпретатора (как и набивший оскомину GIL) являются великолепными отмазками для недостаточно квалифицированных разработчиков. Они не понимают текущее положение вещей, а значит и не могут его существенно улучшить. Зато имеют отличный повод сказать: «Вот если бы не GIL — моя программа летала бы со скоростью света!» Но ведь это не правда. Как правило проблема кроется в другом. Приемлемую скорость можно получить и на имеющемся инструменте. Более того, более быстрый питон мало бы помог: лучший способ ускорения кода с квадратичной сложностью — приведение этой сложности к логарифмической. И так далее.
Резюмируя: плохому танцору ноги мешают.
лучший способ ускорения кода с квадратичной сложностью — приведение этой сложности к логарифмической.
Если бы всё было так просто.
В тот единственный раз, когда мне понадобилось использовать numpy для обработки большого объёма числовых данных (этак на четыре гигабайта), мне было любопытно узнать, что тамошний quicksort с worst case = O(n^2) на этом объёме работает заметно быстрее, чем heap sort с worst case = O(n*log(n)) (неспроста quicksort там используется по умолчанию). Иногда константы при логарифме и степени тоже имеют значение…
Кто же спорит. Сначала — получение метрик, а потом уже оптимизации.
Вы, похоже, путаете — O(n^2) в худшем случае не означает, что алгоритм будет работать медленнее, чем O(n*log(n)), на то он и «худший случай». Оба алгоритма будут O(n*log(n)) на большинстве данных, вопрос в константе, которая у heapsort больше, т.е. он и должен быть медленнее чем quicksort, за исключением worst case.
Разумеется, про то и речь. Best/average/worst у Quicksort O(n log n) / O(n log n) / O(n2), а у Heapsort O(n log n) / O(n log n) / O(n log n). Т.е., теоретически, если о производительности думать только в терминах «линейная/квадратичная/логарифмическая», эти два алгоритма в целом эквивалентны по производительности, разве что quicksort хуже в зоне от average до worst. Практически — выползает константа…
Хорошо, значит сами не путаетесь, только других путаете :) Исходный коммент выглядит так как будто worst перепутан с average: «тамошний quicksort с worst case = O(n^2) на этом объёме работает заметно быстрее, чем heap sort с worst case = O(n*log(n))».
То, что константа у quicksort лучше — это не особенность питона, интернет говорит что это и в общем случае обычно так. Но если вы говорите, что «заметно быстрее», то это уже действительно может быть что-то специфическое в питоне.
То, что константа у quicksort лучше — это не особенность питона, интернет говорит что это и в общем случае обычно так. Но если вы говорите, что «заметно быстрее», то это уже действительно может быть что-то специфическое в питоне.
Андрей, я всё не перестаю удивлятся тому, что тебе не надоедает эти повторять простые истины. Вопрос настолько часто поднимался везде, где обсуждали питон, что я просто перестал на него реагировать.
Ничего, от меня не убудет.
Весь мой блог посвящен прописным истинам — никакой высокой науки.
И, тем не менее, их актуальность не падает со временем.
Более того. Относительно небольшой части специалистов уже давно все известно, они успешно работают и не задают глупых вопросов.
Зато в индустрия постоянно расширяется за счет новичков, которым эти элементарные вещи нужно вдалбливать в голову раз за разом.
Собственно говоря, матерым зубрам не требуются все эти блоги и прочая периодика, толстые книжки и тому подобные результаты творчества. Им достаточно просматривать, скажем, python-dev и список изменений в hg.python.org
Весь мой блог посвящен прописным истинам — никакой высокой науки.
И, тем не менее, их актуальность не падает со временем.
Более того. Относительно небольшой части специалистов уже давно все известно, они успешно работают и не задают глупых вопросов.
Зато в индустрия постоянно расширяется за счет новичков, которым эти элементарные вещи нужно вдалбливать в голову раз за разом.
Собственно говоря, матерым зубрам не требуются все эти блоги и прочая периодика, толстые книжки и тому подобные результаты творчества. Им достаточно просматривать, скажем, python-dev и список изменений в hg.python.org
Да ладно, не прибедняйся, у тебя в блоге много вопросов поднято, которые не обсуждались толком нигде (я имею в виду русскоязычные источники)
Я больше удивляюсь по поводу вопросов, которые настолько часто обсуждались, что не наткнутся на них в поисках ответа невозможно в принципе. Скорость питон-интерпритатора — один из таких вопросов. У меня терпения отвечать на такое не хватает :)
Я больше удивляюсь по поводу вопросов, которые настолько часто обсуждались, что не наткнутся на них в поисках ответа невозможно в принципе. Скорость питон-интерпритатора — один из таких вопросов. У меня терпения отвечать на такое не хватает :)
Было бы здорово иметь лучшую производительность бесплатно, не прилагая никаких усилий.
PyPy вполне живой и развивается. Т.е., он и сейчас уже неплох, а будет ещё лучше.
Мне PyPy будет интересен года через два, если не позже.
Да, проект занятный. Его успехи впечатляют. Но сейчас его использовать все еще нельзя, что бы там не говорили. Хотя бы из-за глюкавой поддержки C Extensions — а это очень много крайне полезных библиотек. Куда без них.
CPython все еще остается единственным реальным выбором.
Альтернативные реализации стремительно развиваются, не могу не признать. Но они до сих пор занимают узкую нишу, интересную лишь немногочисленному количеству людей. Со временем все изменится, конечно. Но — не сейчас.
Да, проект занятный. Его успехи впечатляют. Но сейчас его использовать все еще нельзя, что бы там не говорили. Хотя бы из-за глюкавой поддержки C Extensions — а это очень много крайне полезных библиотек. Куда без них.
CPython все еще остается единственным реальным выбором.
Альтернативные реализации стремительно развиваются, не могу не признать. Но они до сих пор занимают узкую нишу, интересную лишь немногочисленному количеству людей. Со временем все изменится, конечно. Но — не сейчас.
Ну почему же. Если поддержка C Extensions появится не через два года а в скором времени — других причин не пробовать pypy не вижу)
Пробовать можно хоть сейчас.
Поддержка C Extensions есть уже, кажется, около года — но она кривая. NumPy до сих пор не работает, насколько я знаю. Этот вопрос очень непростой. Для IronPython аналогичный проект называется IronClad. Так вот, броненосца делают уже три года — а проблемы все еще остаются.
Зачем мне чудо-инструмент, который временами непредсказуемо ломается? При том, что я уже привык к супер-стабильности Питона как платформы.
Нет, не верю что «в скором времени» PyPy решит эту проблему.
Поддержка C Extensions есть уже, кажется, около года — но она кривая. NumPy до сих пор не работает, насколько я знаю. Этот вопрос очень непростой. Для IronPython аналогичный проект называется IronClad. Так вот, броненосца делают уже три года — а проблемы все еще остаются.
Зачем мне чудо-инструмент, который временами непредсказуемо ломается? При том, что я уже привык к супер-стабильности Питона как платформы.
Нет, не верю что «в скором времени» PyPy решит эту проблему.
На самом деле, рассуждения автора о нерациональности применения LLVM для компиляции Питона кажутся по меньшей мере странными, особенно на фоне успехов Rubinius за последнюю пару лет. Изначально для JIT-компиляции Rubinius использовал GNU-Lightning, но затем они пересели на LLVM и остались весьма довольны результатами. Насколько я могу судить, Python и Ruby очень похожи с точки зрения внутреннего представления. Поэтому странно, что одному языку LLVM подошел, а другому — нет.
С точки зрения производительности Rubinius соперничает с YARV (Ruby 1.9) и JRuby и стабильно опережает MRI (традиционный интерпретируемый Руби), при этом сами разработчики утверждают, что целенаправленно над производительностью они не работают, а все улучшения появляются попутно во время работы над совместимостью с основной реализацией языка и с его следующей версией.
С точки зрения производительности Rubinius соперничает с YARV (Ruby 1.9) и JRuby и стабильно опережает MRI (традиционный интерпретируемый Руби), при этом сами разработчики утверждают, что целенаправленно над производительностью они не работают, а все улучшения появляются попутно во время работы над совместимостью с основной реализацией языка и с его следующей версией.
А внутренности Ruby и Python действительно похожи?
Вы хорошо знакомы с обоими?
Я весьма неплохо знаю внутреннее устройство Питона, а на исходники Руби смотрел только вполглаза.
Вы хорошо знакомы с обоими?
Я весьма неплохо знаю внутреннее устройство Питона, а на исходники Руби смотрел только вполглаза.
Честно говоря, для меня ситуация противоположная — хорошо знаком с Руби, а на Питоне писал небольшие скрипты. Ну, есть довольно много сходств.
Оба языка — объектно-ориентированны, в Руби есть миксины (интерфейсы с реализацией), можно подменить реализацию любого метода в классе (к том числе и в стандартной библиотеке), причем данную подмену можно сделать как для всех объектов класса, так и только для конкретного объекта. Наверняка в Питоне степень свободы сравнима.
В обоих языках есть широкая поддержка лямбда-функций и замыканий, в обоих целочисленный тип умеет «расширяться», когда не хватает разрядности машинного слова, в обоих сообществах есть «текущий» релиз — 2.7 для Питона и 1.8.7 для Руби (оба они страдают наличием GIL, кстати) — и релиз «светлого будущего» — 3.0 и 1.9 — с поддержкой Unicode и прочими плюшками.
Сходств очень много, некоторое время назад был даже такой полушутливый проект Unholy — компилятор Руби в Питон: github.com/whymirror/unholy
Так что, честно говоря, я ожидал, что у Питона на LLVM есть все шансы быть успешным.
Оба языка — объектно-ориентированны, в Руби есть миксины (интерфейсы с реализацией), можно подменить реализацию любого метода в классе (к том числе и в стандартной библиотеке), причем данную подмену можно сделать как для всех объектов класса, так и только для конкретного объекта. Наверняка в Питоне степень свободы сравнима.
В обоих языках есть широкая поддержка лямбда-функций и замыканий, в обоих целочисленный тип умеет «расширяться», когда не хватает разрядности машинного слова, в обоих сообществах есть «текущий» релиз — 2.7 для Питона и 1.8.7 для Руби (оба они страдают наличием GIL, кстати) — и релиз «светлого будущего» — 3.0 и 1.9 — с поддержкой Unicode и прочими плюшками.
Сходств очень много, некоторое время назад был даже такой полушутливый проект Unholy — компилятор Руби в Питон: github.com/whymirror/unholy
Так что, честно говоря, я ожидал, что у Питона на LLVM есть все шансы быть успешным.
Я вполне знаком с Ruby как программист, его использующий. Вопрос был о знании именно внутреннего устройства. Того самого C кода, который и составляет интерпретатор.
Как мне кажется, размышления пошли по не совсем корректному пути. Основные реализации Питона: CPython, Jython, IronPython и PyPy. Пристежкой к CPython идет stackless. Parrot всерьез не рассматриваем.
Язык — один. GIL, кстати, есть не везде.
LLVM совсем не применим даже к PyPy — и тому есть причины. Из сходства языков совсем не вытекает сходство реализаций.
Как мне кажется, размышления пошли по не совсем корректному пути. Основные реализации Питона: CPython, Jython, IronPython и PyPy. Пристежкой к CPython идет stackless. Parrot всерьез не рассматриваем.
Язык — один. GIL, кстати, есть не везде.
LLVM совсем не применим даже к PyPy — и тому есть причины. Из сходства языков совсем не вытекает сходство реализаций.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Unladen Swallow — всё…