Краткий перевод обсуждения Recommendation against Python?:
kng
Я слышал, что сотрудникам Google не рекомендуют использовать Python для новых проектов, что мне кажется глупым, учитывая как много питоновского кода и поддержки самого языка Python исходит из Google. Я начал поиски информации, но ничего не нашел. Вы знаете что-то об этом или это просто слухи?
Collin Winder
Даже простой здравый смысл ограничивает применимость Python, когда речь идет о масшабах Google — он не так быстр как Java или C++, работа с тредами хромает, расходуется больше памяти и т.д. Одно из требований, с которым мы сталкиваемся при проектировании новых систем, это «Что мы будем делать, если нагрузка возрастет в 10 или в 100 раз? Что мы будем делать, если целая планета решит что наш новых сервис офигителен?» Любая технология, которая усложняет соблюдение этого требования — и я считаю, что Python попадает в эту категорию — должна быть отвергнута и даже прочие её полезности не играют важной роли в этом случае. Приходится балансировать слабые и сильные стороны Python — ваши разработчики могут быть более продуктивными, используя Python, но если им придется крепко поработать над масштабированием под большую нагрузку, то удастся ли вам вырваться с Python вперед? И т.д.
…
Unladen Swallow планирует сместить этот баланс — чтобы сделать возможным использовать Python в большем числе проектов, где сейчас его использовать еще нерационально. Но панацеей это не будет. Python все еще будет медленнее, чем C или Java, будет использовать больше памяти и ужасно работать с тредами, пока кто-нибудь не решит инвестировать ресурсы в Python в объеме, сравнимом с ресурсами, которые Sun инвестировала в JVM. Я надеюсь, что внимание к производительности Python со стороны разработчиков будет носить лавинообразный характер — чем больше компаний будет заинтересовано в этом, тем больше ресурсов будет инвестировано, тем больше аспирантов будут работать над Python (и выкладывать результаты своей работы) и т.д.
Luis Gonzalez
Понятно, что Python будет медленне чем C или Java, но мне интересно — как быстро Python (в нашем случае — Unladen Swallow) будет работать по сравнению с js-движком V8? Вы считаете, что можно будет догнать V8? Или потребуется полное переписывание (интерпретатора) для того чтобы догнать его?
Collin Winter
Я не думаю, что возможно сделать реализацию CPython такой же быстрой как движки V8 или SquirrelFish Extreme, которые специально спроектированы для скорости. Мы придумали целый ряд оптимизаций, которые уже сейчас очень сложно реализовать на базе CPython и нам пришлось отказаться от них. Будучи open-source проектом, которым занимаются энтузиасты, CPython диктует другие приоритеты нежели V8 — CPython делает особый упор на простоту, на идею, что простое медленное ядро проще для поддержки людьми, которые занимаются им в свободное время, чем более сложное быстрое ядро.
Я надеюсь, что одна из альтернативных реализаций Python добьется в конечном итоге серьезного выигрыша в производительности без привязки в обратной совместимости на уровне C (с CPython). Мы же действуем в границах «Что нам предпринять, чтобы сделать вещи лучше прямо сейчас?», в то время как проекты типа PyPy работают с производительностью в перспективе «Что нам предпринять, если мы готовы потратить десять лет, чтобы сделать все действительно правильно?».
Tom Machinski
Как насчет Cython?
…
Похоже он удовлетворят обоим требованиям, которые упомянул Collin:
1. Это технология, которую можно использовать прямо сейчас
2. Она предлагает серьёзное увеличение производительности
Может быть для Google имеет смысл сначала прототипировать на Python, а затем переносить критические к производительности места на Cython, предлагающий преимущества чистого Python вместе с близкими к C эффективностью и оптимизационным потенициалом?
Craig Citro
Я считаю что это годится для написания нового кода на Python. В частности, мы так и используем Cython в библиотеке Sage — пишем код и добиваемся корректной работы на Python, обкладываем его тестами, а затем переводим самые нагруженные куски на Cython. Тем не менее, я думаю что комментарии Collin даны в контексте ускорения работы всего существующего Python-кода в Google, без необходимости изменения исходников. В частности, необходим инструмент, который можно использовать не волнуясь о случайных багах, которые могут появиться в некоторых граничных случаях (например, из-за отличий арифметической семантики в C и Python).
…
Cython и Unladen Swallow — ортогональны в некоторых смыслах. В частности, с использованием LLVM (low level virtual machine), у Unladen Swallow есть перспективы в добавлении рантайм оптимизации и специализации, которые Cython никогда не сможет сделать.
Collin Winter
Ускорение явных сложных мест — самая легкая часть оптимизации. Ты кодируешь их на C, используешь инструменты типа Cython, подключаешь Psyco и т.д. Мы же работаем над ускорением работы всего приложения от начала и до конца без необходимости в специальных инструментах, чтобы производительность была более адаптивна к изменению кода, и над ускорением существующего языка Python без его расширения. Мы считаем, что такие расширения и исключения (имеются в виду type hints в Cython) повышают порог сложности при передаче кода другим разработчикам, повышают количество потенциально проблематичных граничных случаем, и увеличивают затраты на обучение, необходимое инженерам для написания Python приложений.
В переписке есть еще много интересного, рекомендую к прочтению!
(Оригинал статьи в моем блоге)
kng
Я слышал, что сотрудникам Google не рекомендуют использовать Python для новых проектов, что мне кажется глупым, учитывая как много питоновского кода и поддержки самого языка Python исходит из Google. Я начал поиски информации, но ничего не нашел. Вы знаете что-то об этом или это просто слухи?
Collin Winder
Даже простой здравый смысл ограничивает применимость Python, когда речь идет о масшабах Google — он не так быстр как Java или C++, работа с тредами хромает, расходуется больше памяти и т.д. Одно из требований, с которым мы сталкиваемся при проектировании новых систем, это «Что мы будем делать, если нагрузка возрастет в 10 или в 100 раз? Что мы будем делать, если целая планета решит что наш новых сервис офигителен?» Любая технология, которая усложняет соблюдение этого требования — и я считаю, что Python попадает в эту категорию — должна быть отвергнута и даже прочие её полезности не играют важной роли в этом случае. Приходится балансировать слабые и сильные стороны Python — ваши разработчики могут быть более продуктивными, используя Python, но если им придется крепко поработать над масштабированием под большую нагрузку, то удастся ли вам вырваться с Python вперед? И т.д.
…
Unladen Swallow планирует сместить этот баланс — чтобы сделать возможным использовать Python в большем числе проектов, где сейчас его использовать еще нерационально. Но панацеей это не будет. Python все еще будет медленнее, чем C или Java, будет использовать больше памяти и ужасно работать с тредами, пока кто-нибудь не решит инвестировать ресурсы в Python в объеме, сравнимом с ресурсами, которые Sun инвестировала в JVM. Я надеюсь, что внимание к производительности Python со стороны разработчиков будет носить лавинообразный характер — чем больше компаний будет заинтересовано в этом, тем больше ресурсов будет инвестировано, тем больше аспирантов будут работать над Python (и выкладывать результаты своей работы) и т.д.
Luis Gonzalez
Понятно, что Python будет медленне чем C или Java, но мне интересно — как быстро Python (в нашем случае — Unladen Swallow) будет работать по сравнению с js-движком V8? Вы считаете, что можно будет догнать V8? Или потребуется полное переписывание (интерпретатора) для того чтобы догнать его?
Collin Winter
Я не думаю, что возможно сделать реализацию CPython такой же быстрой как движки V8 или SquirrelFish Extreme, которые специально спроектированы для скорости. Мы придумали целый ряд оптимизаций, которые уже сейчас очень сложно реализовать на базе CPython и нам пришлось отказаться от них. Будучи open-source проектом, которым занимаются энтузиасты, CPython диктует другие приоритеты нежели V8 — CPython делает особый упор на простоту, на идею, что простое медленное ядро проще для поддержки людьми, которые занимаются им в свободное время, чем более сложное быстрое ядро.
Я надеюсь, что одна из альтернативных реализаций Python добьется в конечном итоге серьезного выигрыша в производительности без привязки в обратной совместимости на уровне C (с CPython). Мы же действуем в границах «Что нам предпринять, чтобы сделать вещи лучше прямо сейчас?», в то время как проекты типа PyPy работают с производительностью в перспективе «Что нам предпринять, если мы готовы потратить десять лет, чтобы сделать все действительно правильно?».
Tom Machinski
Как насчет Cython?
…
Похоже он удовлетворят обоим требованиям, которые упомянул Collin:
1. Это технология, которую можно использовать прямо сейчас
2. Она предлагает серьёзное увеличение производительности
Может быть для Google имеет смысл сначала прототипировать на Python, а затем переносить критические к производительности места на Cython, предлагающий преимущества чистого Python вместе с близкими к C эффективностью и оптимизационным потенициалом?
Craig Citro
Я считаю что это годится для написания нового кода на Python. В частности, мы так и используем Cython в библиотеке Sage — пишем код и добиваемся корректной работы на Python, обкладываем его тестами, а затем переводим самые нагруженные куски на Cython. Тем не менее, я думаю что комментарии Collin даны в контексте ускорения работы всего существующего Python-кода в Google, без необходимости изменения исходников. В частности, необходим инструмент, который можно использовать не волнуясь о случайных багах, которые могут появиться в некоторых граничных случаях (например, из-за отличий арифметической семантики в C и Python).
…
Cython и Unladen Swallow — ортогональны в некоторых смыслах. В частности, с использованием LLVM (low level virtual machine), у Unladen Swallow есть перспективы в добавлении рантайм оптимизации и специализации, которые Cython никогда не сможет сделать.
Collin Winter
Ускорение явных сложных мест — самая легкая часть оптимизации. Ты кодируешь их на C, используешь инструменты типа Cython, подключаешь Psyco и т.д. Мы же работаем над ускорением работы всего приложения от начала и до конца без необходимости в специальных инструментах, чтобы производительность была более адаптивна к изменению кода, и над ускорением существующего языка Python без его расширения. Мы считаем, что такие расширения и исключения (имеются в виду type hints в Cython) повышают порог сложности при передаче кода другим разработчикам, повышают количество потенциально проблематичных граничных случаем, и увеличивают затраты на обучение, необходимое инженерам для написания Python приложений.
В переписке есть еще много интересного, рекомендую к прочтению!
(Оригинал статьи в моем блоге)
