Comments 37
Какой адский нейрослоп...
Никогда не понимал причем тут сам язык. Все дело в компиляторе.. или в не-компиляторе.
Тормозит-то бинарник, который (грубо) из исходника создал компилятор.
А на каком языке написан исходник рояли не играет.
Согласен, тормозит бинарник, а не синтаксис. Но язык задаёт компилятору потолок: пока спецификация разрешает в рантайме переопределить любой метод и атрибут, компилятор обязан оставлять динамический диспатч. Поэтому 30 лет и миллиарды в PyPy/Faster CPython дали ~1.4x. А раздел 3 как раз о том, что в ИИ быстрый бинарник и так на C++/CUDA; вопрос лишь, почему исходник над ним обязан быть именно на Python. И ответ не технический, а социальный.
В языке, кроме синтаксиса, есть и семантика. Язык определяет, что программа знает о данных, с которыми работает, и какие преобразования допустимо делать. В Python программа довольно мало знает о данных и мало что имеет право делать в плане “срезания углов”. Видя, например, запись a + b, компилятор C++ имеет право ругнуться, если обнаруживает, что для типов переменных a и b не определён operator+. Python же не знает, что там за типы. Не знает, определено для них суммирование как встроенная функция, или нужно будет вызвать a.__add__(b), или b.__radd__(a). Более того, в Python объекты одного и того же типа не обязаны иметь одинаковые атрибуты. По сути, объект - это словарь, из которого по имени достаются атрибуты. Поэтому на любой чих там поиск по хэш-таблице, несколько переходов по указателям и динамический диспатч. Сгенерировать эффективный машинный код заранее не представляется возможным. Если убрать такой беспредельный динамизм - получится что-то типа Julia, где, действительно, всё компилируется +/- в такой же код, что и в Си. Но, как заметил автор, там пока что не просматривается надежда на помощь крупных корпораций в создании ИИ-стека, поэтому там возможности очень неоднородные, может всё работать идеально и быстро, а можно оказаться перед необходимостью с нуля писать движок. Отдельно надо сказать, что когда появлялся Python, компиляторы не очень умели автоматически выводить типы, когда они явно не указаны. Поэтому вопрос пригодности скриптового языка для компиляции в принципе на повестке не стоял - всё, что без явной типизации, рассматривалось как неизбежно медленное.
Спасибо, вы сформулировали точнее меня. Именно поэтому "просто напишите умный компилятор" и не работает: раз объекты одного типа не обязаны иметь одинаковый набор атрибутов, а любой из них можно переопределить в рантайме, компилятор обязан оставлять полный динамический поиск. Это потолок семантики, а не лень авторов CPython.
Все скоростные алгоритмы, в т.ч. перемножение матриц, выполняются не на чистом python, а в библиотеках, которые как раз и написаны на быстрых энергоэффективных языках.
На чистом python выполняются лишь небольшие по объему эксперименты, на домашних х компьютерах, которые если и увеличивают потребление, то на мизерные доли по сравнению с просмотром видео или видеоиграми...
Вот вам код llm на чистом python: https://habr.com/ru/articles/996404/
Те, кто занимался оптимизацией систем в один голос скажут, что не существует одного-двух узких мест.
Быстродействие это культура производства, здесь нет мелочей.
Python очень медленный язык; сколько его не ускоряй - ничего не получится, зависимости вмешаются. Типизация вообще загадочная.
Только куда не ткнись, язык python не обойти.
Согласен по всем пунктам, кроме "не обойти" - это верно там, где Python держится на инерции экосистемы. А на новых территориях его уже обошли, даже HuggingFace пишет ядро на Rust. Так что да — вниманием стоит не обходить и Swift, и Rust, и Mojo. Победа любого из них лечит главную болезнь: привычку писать всё на двух языках сразу.
его уже обошли, даже HuggingFace пишет
Пожелаем им удачи.
Нейронные модели сильно облегчили написание кода, только учитываем что Rust разработчик дороже в деньгах и rust сложнее в разработке и в менеджменте.
И второе - переписать программный код на другой язык - это на порядки раз проще и понятнее чем написать с нуля, потому что весь путь уже пройден, уже знаем что нужно делать.
Для языка python даже не очень современные модели выдают безупречный код, по цене "почти бесплатно". Для прототипа хватит, а без прототипа ничего не получится.
Разработка на python на порядок быстрее и проще (сравнивая с Rust, Go, C, C++) - по времени, по деньгам, по ошибкам, по рефакторингу. То есть для прототипов других вариантов почти нет. На практике новый проект пишем на python, а уже потом, через года, если проект взлетит, если будет бюджет - перепишем на компилируемый язык.
Разработка на python на порядок быстрее и проще (сравнивая с Rust, Go, C, C++) - по времени, по деньгам, по ошибкам, по рефакторингу.
Я правильно понимаю, с Ваших слов,что приложение на python можно написать быстрее чем на Go в 10 раз?
приложение на python можно написать быстрее чем на Go в 10 раз?
Правильно понимаете. Столько проверенных на проде библиотек, сколько есть у python, вряд ли есть у какого другого языка. Особенно если нужны AI/ML, матричные вычисления, тензора. На других языках есть одна, может быть две библиотеки и всё.
И готовый проектов на python в разы больше.
Есть разной глубины задачи, python справится почти со всем, на всех платформах, под любое железо.
"Медленность" питона никак не мешает ИИ задачам. Все тяжёлые и массовые операции, типа перемножения тензоров (основная операция для ИИ) давно реализованы в идеально оптимизированных сишных библиотеках, а питоновские скрипты просто позволяют удобно склеивать логику. Перевод этой логики на компилированные языки мало что добавит скорости, но повредит гибкости.
"На C можно написать все что угодно, но жизнь слишком коротка", уже не помню откуда в голове у меня эта фраза, но в целом я потратил 6 лет жизни на этот язык, сейчас работаю на питоне и js, ну и на Rust чучуть и я пипец как этому рад, терпеть не могу C++ и C.
В целом бизнесу не важно на чем ты пишешь проект и быстрый ли он, это наш инженерский прикол, важна лишь скорость доставки фичей и скорейший запуск продукта, остальное издержки... Так что пишите на чем нравится, а пару сэкономленных мс, ни кто не заметит, а вот пару дополнительных месяцев работы дорогого разраба бизнес очень сильно ощутит
В статье подчёркивается применение python для ИИ. Тут уже важно на чём написан проект, python на минимально реальных датасетах настолько медленный, что кажется выполнение зависло.
Согласен. После C/C++ Python и JS — это действительно облегчение, и бизнесу важнее всего скорость вывода фичей, а не пара миллисекунд.
Просто в on-device AI эти миллисекунды уже заметно влияют на батарею и стоимость серверов. Поэтому и предлагают Swift - удобство почти как у Python, но без сильного налога на производительность.
Вот вообще не универсально.
Попробуйте бизнесу предложить, например, HTTP-сервер на Python.
А что не так с HTTP сервером на питоне? Почему то все говорят про нагрузку фрейм ворка языка, но про нагрузку на все остальное рядом все молчат. У вас быстрее база данных захлебнется в нагрузке чем приложение на питоне или вообще на чем угодно, + вашему приложению еще дорасти надо до такой нагрузки, не у всех и будет такая нагрузка хоть когда нибудь что бы хоть какой-то смысл имело писать дольше на более производительном языке
Справедливо: для I/O-bound веба скорость языка почти не важна, там правит удобство. Тезис статьи узкий - про compute- и energy-bound задачи ИИ, где оверхед виден. Спасибо, это стоило проговорить явно.
Да, понятно, что и с HTTP сервером есть множество сценариев использования, но зачастую требуется производительный сервер. Как реальный пример - мы сейчас выжимаем из нашего S3 сервера каждую миллисекунду (собственные аллокаторы, CPU affinity для потоков, io_uring, кеширование всего, что можно и еще кучу всякого). Я боюсь представить, как бы он работал на Python.
И все те же техники есть, например, в Nginx.
Интересно, иногда считаешь, что есть вещи, которые известны всем, а потом понимаешь, что в статье и в комментариях уже раз 10 в разных формулировках упомянуто, что «все ключевое в питоне написано на C/C++”.
А еще, я может и не прав, но чтобы заменить собой питон, даже если язык справится с его требованиями на простоту использования и порог входа, то столкнется с тем, что мегатонны кода уже написаны на питон, и должны пройти многие годы нереального превосходства, чтобы люди перешли на другой язык.
А еще, я может и не прав, но чтобы заменить собой питон, даже если язык справится с его требованиями на простоту использования и порог входа, то столкнется с тем, что мегатонны кода уже написаны на питон, и должны пройти многие годы нереального превосходства, чтобы люди перешли на другой язык.
С одной стороны да, поскольку так уже было с выходом Python 3 - что-то так до сих пор и работает на Python 2, потому что переписать дороже, чем поддерживать. С другой стороны, если вдруг весь FAANG начнёт от питона избавляться, остальные тоже, скорее всего, будут смотреть в ту же сторону.
Питон в топку, разумеется.
Но Swift - это же apple-only язык?
Python очень не хватает нормальной имплементации - JIT или компилятора в стиле SBCL. Да, конечно, есть PyPy...
Даааа, статью наверное блокнут за ллм
Но блин, вот точно такая же ситуация с react и $mol'om )
Питон на реакт заменить а всё остальное на мол)
Спросите меня, что будут обсуждать на Хабре через двадцать лет? Правильно. Ругать пайтон за медлительность и удивляться, почему это до сих пор самый востребованный язык во всём мире.
Через 20 лет он вряд ли будет востребованным )
Вообще, популярность питона обусловлена другой причиной. Нейросетями сначала занимались математики. Не являясь программистами, они лабали свои наброски на максимально легком для входа языке - питоне. И получилось, что множество библиотек для ML написано на нем. Автоматически, те, кто присоединялся к ML\LLM тематике, были вынуждены использовать питон.
Но думаю, с массовым распространением LLM, ситуация измениться в правильное русло. Пример - llama.cpp.
>популярность питона обусловлена другой причиной
все проще - питон там - это учебный язык. и многие только им и довольствуются
Переоценённый король