раскрыть ветку (54)
раскрыть ветку (49)
-- Поспешишь - людей насмешишь. С чувством, с тактом, с расстановкой. Кто понял жизнь - тот не спешит. Тише едешь - дале будешь. Торопиться жить - скоро умереть...
-- Сайпал, подключай сишные библиотеки...
-- Готово! Эх! Какой же русский не любит быстрой езды... Долго ходить - мертвого родить, Последнего и собаки рвут. Наш пострел везде поспел...
А вот с этого места поподробнее, пожалуйста) Какие задачи вы решаете, что разница в производительности в реальных ситуациях становится хоть сколько-нибудь заметна? Пишете движки для 3D-игр? Или просто слышали где-то, что плюсы быстрые, а питон медленный, и теперь повторяете эти слова?)
раскрыть ветку (43)
Единственное, где на практике роляло, это обработка сетевого трафика, но это у меня. А так в целом любые задачи по вычислению/обработке, где овермного данных. Разница достаточно заметна
раскрыть ветку (8)
ещё комментарии
ещё комментарии
раскрыть ветку (1)
Ну тогда и большая часть кода выполняется на стороне numpy и даже глубже, а это, на минуточку, уже не python.
Еще сравнивал алгоритм подбора значений решения задачи и на питоне не дождался когда все варианты переберет, а на си все за несколько секунд решилось.
раскрыть ветку (10)
Так в Питоне куча либ написана на Си, откуда такая разница? Или у вас прога чисто самописная?
раскрыть ветку (8)
Самописная. И если язык использует либы на си, то это уже не совсем честно получается. А если мне что-то дописать надо свое или ошибки есть?
раскрыть ветку (7)
А если вы откроете файл, а там крокодил?
Вы рассматриваете мутно-гипотетические ситуации, которые не произошли и навряд ли произойдут. Выражаясь проще, пытаетесь натянуть сову на глобус, чтобы доказать свою правоту.
Давайте я так же сделаю: пишите на C, но не используйте компилятор, потому что так нечестно, это уже не C, а ASM! И вообще, как можно использовать C? А если вам понадобится дописать что-то своё или ошибки есть?
Ну как, работает это в другую сторону, или "этодругое"?)
Всё просто: в языке есть инструменты. Вы не пользуетесь ими, вместо этого зачем-то пытаетесь то же самое реализовать вручную, а потом говорите, что "всё плохо и медленно". Можно забивать гвозди отверткой, но если плохо получится, то это не отвертка плохая, это с пользователем что-то не в порядке.
раскрыть ветку (1)
Представляете, в библиотеках не всегда есть все что надо или бывают ошибки. Но когда я дописываю на си или асме то мой код работает примерно так же быстро как библиотечный, а в питоне это будет узким местом.
И вообще, спор ни о чем. Разные задачи - разные инструменты. Хотите писать быстро и строк поменьше - питон, хотим максимальной производительности - пишем на си.
раскрыть ветку (4)
раскрыть ветку (3)
Не зря питон считается лучшим языком для ученых и дата саейнистов и т.д. Там надо обрабатывать много данных. И тот же нампай дает перфоманс близкий к голому С. Но позволяет в одну строку сделать то, что на С придется исписывать сотнями строчек кода. Так что в этом контексте питон лучше С. Хотя проще сказать где-он не лучше.
раскрыть ветку (1)
Есть. Это sbcl и common lisp. Самая интерактивная разработка там) Можно каждую функцию компилировать по отдельности в запущенном процессе.
У нас есть процесс обработки нескольких десятков миллионов записей. Код был на питошке. После переноса кода на ООП, процесс стал занимать вместо пары дней - пару часов, заказчик доволен.
раскрыть ветку (8)
Интересно, а причём тут ООП? ООП всё же влияет на поддерживаемость, а не производительность. Конечно, попутно можно было оптимизаций намутить, но к чему тут упоминание ООП, который в общем случае производительность незначительно снижает.
раскрыть ветку (1)
После переноса на ООП? 😄
Судя по тому, что вы не понимаете значение базовых терминов, вы в реальности не писали ничего сложнее хелловорлда.
И судя по тому, что у вас десяток миллионов записей обрабатывался пару дней, вы даже не знакомы с реальными масштабами того, что сейчас происходит в обработке данных и выдумываете на ходу. Чтобы 10**7 записей обрабатывалось несколько дней, нужно либо код запускать на одноядерном калькуляторе 166 MHz, либо максимально всрато написать код с O(n**3). В обоих случаях проблема решается путем замены прослойки между креслом и монитором.
раскрыть ветку (3)
раскрыть ветку (2)
asm слишком непереносимо между разными платформами, а плис пока не нужна настолько. Это если б непрерывно надо было анализ делать.
раскрыть ветку (1)
раскрыть ветку (3)
И почему это я не должен говорить про Numpy, если это один из самых популярных инструментов в инфраструктуре Python, который как раз создан для операций над многомерными данными, в частности, для перемножения матриц? Ага, он написан на C. И вот вам шок-контент - сам Python тоже написан на C :)
Давайте тогда Java тоже считать недоязыком, ведь JVM пишется на C / C++. Или "этодругое"?)
А C++ вообще нельзя всерьёз рассматривать, потому что на самом деле там gcc всё превращает в бинарный код. Давайте рассмотрим Python без Numpy, а C++ без компиляции. Вот это будет абсолютно честно, да?)
раскрыть ветку (2)
Вы серьёзно приравниваете язык к внешней библиотеке? Какая разница на чем написан питон, он идеологически не может иметь на стеке объекты и иметь статическую типизацию. А это значит, что есть вещи которые он в принципе сделать не сможет. Собственно как и любой другой язык. Так же как джава. У таких языков ты не отключишь например GC. И ты хоть по обширяйся библиотеками, ты не то что не будешь быстрее, ты даже на тот же порядок по производительности не выйдешь. И всерьёз дискутировать на тему кто быстрее: питон или плюсы в 2024? Серьёзно? Вы бы ещё начали спорить об удобстве ассемблера.
раскрыть ветку (1)
раскрыть ветку (1)
Давайте конкретнее.
Данные на диск писать? Если вы это делаете с помощью нативного кода на Python, а не используете СУБД, то это проблема не в языке, а в программисте.
У вас 100к+ RPS? Ну тут моё уважение, вы работаете над крупнейшими проектами, которые 99% программистов и не снились. Только обобщать этот 1% на остальные 99% не нужно.
Или есть что-то ещё, что я упустил? Подскажите, пожалуйста.
Или просто слышали где-то, что плюсы быстрые, а питон медленный, и теперь повторяете эти слова?
Даже если просто слышал то как это меняет неоспоримый факт?)
раскрыть ветку (2)
Факт в том, что никто из _настоящих_ программистов, не работающих в специфичных областях вроде геймдева, не ноет из-за того, что на питоне медленно работают числодробилки. Потому что если вы не работаете с CPU-bound задачами, то вам производительность языка вообще никуда не упёрлась. На фоне того, сколько времени данные будут ходить по сети и считываться\записываться в БД, вы времени работы клиентского кода даже не заметите.
Хотите поспорить? Напишите супер-крутой-быстрый-мощный вебсервер на C++, а я напишу такой же на медленном-стремном-неклассном FastAPI. Нагрузим их одинаково реалистичными запросами, и о чудо, вы внезапно обнаружите, что разницы-то и нет, только вы на написание своего супер-крутого кода потратили в 20 раз больше времени, чем я.
раскрыть ветку (1)
1) Вы уже подменяете изначальный тезис о том что питон медленнее c++ на другой что скорость Python не важна. Подмена тезиса == балабольство и демагогия.
2) Был опыт переписывания сервиса с node.js на rust. Сервис ходил в сеть и парсил xml выдирая оттуда некоторые данные с RPS > 10k. С 2000 vCPU было уменьшено до 100 vCPU и p99 max latency улучшено в два раза. С Python это было бы явно даже не 2000.
Так что я не вижу нужды спорить.
Да когда он на С++ писал, он подбухивал, там платят больше, кэш был. А когда на Питоне писал, он смеялся от уровня зарплаты
