Комментарии 89
Действительно. Но кому это нужно? Оптимизация настолько дорого стоит что никто не заплатит и дешевле наращивать гигабайты.
Ну и например как не старайся, уместить сериал Карточный домик в дискету 3.5 не получается
Вы вряд ли поверите, но оптимизация во многих случаях не стоит вообще ничего, и более того, зачастую обходится дешевле, чем писать и сопровождать неоптимальный код. Просто... это тоже никому не нужно, т.к. до недавнего времени за софт платили столько, сколько попросят (да и сейчас многие по инерции всё ещё платят).
Вряд ли поверю потому что я было недели рабочего времени проводил над оптимизацией, никогда идеальный код не напишешь. Может ИИ будет писать идеально, не знаю, я - при всем моем желании и опыте - все равно делаю ошибки, хотя можно потратить больше времени и сделать лучше. В разы больше.
Оптимальный код - это не тот код, который вы неделю полировали, экономя килобайты и пару циклов. Оптимальный код, это код, в котором у вас не тянется стопицот тривиальных зависимостей, которые можно заменить на несколько своих строк. Это код, в котором у вас не компонуются чужие здоровенные компоненты, из которых вы потребляете 1% функционала. Код, в котором у вас нет вертикальной иерархии из вызовов микросервисов, и который не имеет в зависимостях исполняемую среду пайтона, хотя сам написан на чём-то другом.
Может ИИ будет писать идеально
ИИ, который учился на таком же коде, как и везде? Не та технология :)
Экономя килобайты? У нас 100 Gbps трафика, используется 500 CPU cores и 300 Gb ram. И никакого пайтона.
А 1% удаляется линковкой только до нужного функционала
Конечно идеально было бы пойти в asm и использование sse и других оптимизаций, но хоть и можно было бы попробовать - добро не дадут. Это сложно тестировать и не читаемо
А насколько эти cpu нагружены?)
можно было бы попробовать - добро не дадут.
Ничего, у бизнеса потом на консультантов со стороны и деньги и добро найдется.
Это сложно тестировать и не читаемо
Не голый asm, а интринсики; не замена, а параллельная реализация горячих функций?
Дело в том, что с точки зрения бизнеса всё и так хорошо. Оптимизация понадобится когда-то потом.
И это на самом деле правильно - был бы я директором - меня бы не беспокоили каких то 500 ядер. Пока это работает, бюджет это осиливает, и всех всё устраивает. Технари не приоритет - надо продукт продавать.
И , конечно , бывают продукты, где скорость важна. Без неё ничего не продать. Но очень много таких - где оптимизация второстепенна. Например игры. Главное продать, даже если на 5090 лагает - потом доработают
Всё так. Если в случае бизнеса я вижу и понимаю другой mindset (отличное высказывание: "it's the cost of doing business"), то по играм у меня на уму другое: "лох -- не мамонт; лох не вымрет."
И это на самом деле правильно - был бы я директором - меня бы не беспокоили каких то 500 ядер. Пока это работает, бюджет это осиливает, и всех всё устраивает.
А я, если был бы директором, задал бы себе сперва вопрос, какой запас прочности у нашего бизнеса, и хватит ли у нас времени и денег урезать прожорливость инфраструктуры до того, как бизнес сдохнет от кассового разрыва, если (или даже когда) наступит период, когда бюджет расходы на неё перестанет осиливать.
То то американские стартапы в топе всех рейтингов, а русские ну как-то держатся на плаву. Правильно приоритеты расставляют - инфраструктура всё ещё дешевле разработчиков, а сдохнет так сдохнет, все мы умрём рано или поздно, можно принять за аксиому. Но и русские есть очень интересные, у меня нет каких то приоритетов - статистика
То то американские стартапы в топе всех рейтингов
В топе всех рейтингов единицы стартапов. А те тысячи стартапов, которые сдохли, нам свои истории успеха не рассказывают.
Правильно приоритеты расставляют - инфраструктура всё ещё дешевле разработчиков
А это смотря сколько у вашей компании денег. Если вдруг на рынке неблагоприятная ситуация с продажами вашего продукта, вы можете приостановить разработку и уволить разработчиков, и ваш бизнес выживет. Но вы не сможете уволить инфраструктуру, потому что она и есть неотъемлемая часть продукта. Когда экономика на подъеме, денег в ИТ инвесторами вбухивается много, все живут хорошо. А вот когда наступают кризисы, умирают те, у кого постоянные издержки (в частности, инфраструктура) слишком высоки. Те же, кто её оптимизировал, те выживают
Экономя килобайты? У нас 100 Gbps трафика, используется 500 CPU cores и 300 Gb ram. И никакого пайтона.
Мне без дополнительных подробностей это ничего не говорит. Вы можете попасть в те немногочисленные технологические компании, где куча вычислительных мощностей делают эффективную полезную работу, или в те куда более многочисленные компании, где куча вычислительных мощностей в лучшем случае простаивает, а в худшем процентов на 90 загружена поддержкой инфраструктуры, т.е. является прожорливой вещью в себе.
К сожалению, это почти бесполезный подход в оптимизации бека. Фронт ещё можно оптимизировать, убрав зависимости, но на бек это повлияет слабо, так как проблемы очень часто чуть сложнее, а потери больше, чем от подгрузки пакета (хотя допускаю, что в вашем случае других проблем не встретилось и лишние пакеты правда были самым медленным звеном)
Ну пакеты бывают разные.... Например std\jsonи bytedance\sonic (я сейчас на го пишу) , но кто-то предпочитает вообще самому всё писать без лишних зависимостей и думает так лучше - его дело
Самая частая проблема бэка - инфраструктура, которая не соответствует его потребностям. Грубо говоря, компания имеет кубернетис с пачкой узлов, на каждом гроздь микросервисов, и для пущей гибкости они ещё и общаются между собой через сервис бас. Платит компания за это 10К в месяц, не считая зарплаты админа и девопса. При этом весь требуемый функционал с их текущей нагрузкой прекрасно помещается в одно приложение, работающее в одном инстансе, и ещё будет десятикратный запас для роста.
Покажите мне сервер с 500 ядер без кубернетисов . Оптимизация конечно ещё место имеет, но когда-то она заканчивается, а ресурсы на монолите заканчиваются быстрее.
Можно конечно гвозди забивать кувалдой. И не всем микросервисы подходят и накладные расходы имеют свою цену .
Но я не знаю как на одном сервере , пускай самом самом, обеспечить отказоустойчивость, масштабируемость и стрессоустойчивость. Максимум монолита есть максимум
Покажите мне сервер с 500 ядер без кубернетисов
Не покажу, но могу показать сервер с 16 ядрами без кубернетисов, который может заменить сервер с 500 ядрами с кубернетисом. Это - тоже оптимизация.
И не всем микросервисы подходят и накладные расходы имеют свою цену .
Фишка в том, что большинству микросервисы излишни. Может быть, даже подавляющему большинству. Если ваш проект, это нечто размером пусть не с Фейсбук, но хотя бы с Вайлдбериз, то микросервисы - ваша технология. Но сколько в стране проектов размером с Вайлдбериз? Сотни две наберётся? А сколько десятков тысяч проектов с микросервисами?
Веселее всего, если на питоне написан только скрипт для сборки, но питон почему-то всё равно в рантайм-зависимостях.
Оптимальный код, это код, в котором у вас не тянется стопицот тривиальных зависимостей, которые можно заменить на несколько своих строк.
Это ж что ж там нужно делать, чтобы главной проблемой оптимизации стали зависимости? Причём, не на клиентских машинах. Даже интересно увидеть.
На одной из прошлых работ пришли заказчики - с ростом пользователей у них уже 2 раза апгрейдили сервер БД, но всё равно загрузка ЦПУ 100% и сервис ложится, хотя пользователей всего несколько тысяч. Только вычистив конструкции а-ля вложенные циклы с инсертом/аптейтом в таблицу по одной строчке там, где уместен batch insert/нормальный update, и переписав дважды-трижды вложенные селекты в нормальные join я почти вполовину снизил нагрузку. Да, мы не гугл в силиконовой долине, а шарашка петросяна в мухосранске, но и такую лапшу не надо писать. Так что оптимизация - она бывает разная. Кто-то экономит килобайты и пару циклов, кто-то убирает ненужные зависимости, а кто-то подтирает за нерадивыми погромистами.
Удвою. В 80% «оптимизаций» закладывается на этапе первичного написания кода. Главное не стесняться думать головой.
Но ведь не всегда удаётся угадать будущее продукта.
Есть одно правило, которое вот вообще никогда не подводит: если у вас нет данных о потребностях в масштабировании в будущем, значит, вам сейчас ничего дополнительного для масштабирования делать не нужно. Если вдруг ваш продукт окажется мегапопулярным, и вы будете наблюдать стабильный рост нагрузки, вот тогда вы сядете и будете работать над масштабируемостью. Благо, тогда ваш продукт уже будет работать, и у вас ещё и денег больше будет.
Именно это я имею в виду.
А некоторые в неё, увы, едят...
Оптимизация бывает разной. Часто оказывается, что максимально производительный код - это часто очень лютое Г, которое сильно заточено под особенности железа, которое дорого писать и дорого поддерживать, но которое позволяет выжать всё, что возможно.
Например, если речь про Java, то привет Unsafe, anligned/unaligned memory access, false sharing etc.
Сравните эти две имплементации, которые делают одно и тоже:
https://github.com/gunnarmorling/1brc/blob/main/src/main/java/dev/morling/onebrc/CalculateAverage_baseline.java
и
https://github.com/gunnarmorling/1brc/blob/main/src/main/java/dev/morling/onebrc/CalculateAverage_thomaswue.java
Вы всё ещё будете утверждать, что "во многих случаях не стоит вообще ничего"? Почти всегда оптимизировать можно очень сильно. Но всё упирается как раз таки именно в стоимость.
Стадии развития проектов — кривая им. Ш - https://habr.com/en/companies/jugru/articles/338732/
Это красная зона по второй ссылке.
Оптимизация бывает разной. Часто оказывается, что максимально производительный код - это часто очень лютое Г
Оптимальный код, если не иметь в виду какие-то специфические расчётные применения - это не максимально производительный код. Я бы сказал, что это максимально простой и понятный код без излишеств, в то же время не настолько простой, чтобы быть откровенно тормознутым.
Это ваше субтекивное мнение. На практике "оптимальность" кода - не универсальное понятие, а зависит от требований к нему (коду). В частности, смотрите упомянутый выше докалад Шипелёва: https://habr.com/en/companies/jugru/articles/338732/
На практике "оптимальность" кода - не универсальное понятие, а зависит от требований к нему (коду)
Оптимальность кода зависит от требований весьма опосредованно. Я именно это и написал - если не иметь в виду какие-то специфические расчётные применения, т.е. когда эти самые требования есть, по скорости, по памяти, по алгоритмам. Практически во всех остальных случаях нет никаких требований к коду, кроме того, чтобы он выполнял поставленную задачу. А вот оптимальный он или нет, это уже его качественная характеристика, ортогональная требованиям.
Какая интересная позиция. Каждый второй программист не может ничего оптимизировать, потому что не умеет (кроме совсем уж тривиальных вещей). Каждый второй менеджер не знает, что делать, кроме как попросить «тормозит, сделай что-нибудь». И каждый первый пользователь слишком далеко от разработки, что бы сообщить о проблеме и о том, что она важна для него.
уместить сериал Карточный домик в дискету 3.5 не получится
Карточный домик может и нет, но очень крутые вещи умудряются вместить в 64 кб
Да, оптимизация просто так не даётся. И чем она выше, тем сложнее разрабатывать. Но есть ощущение, что сейчас много где достаточно применить 20% усилий, чтобы получить прирост на 80%. Но на это забивают
очень крутые вещи умудряются вместить в 64 кб
Проблема в том, что это, своего рода, «подгонка задачи под ответ». То есть не получится создать произвольную анимацию, а только найти некий компактный алгоритм, который бы выдавал картинку, подходящую под сценарий. Притом во многих случаях экономия на размере бинарника приводит к несоразмерным требованиям к производительности.
как не старайся, уместить сериал Карточный домик в дискету 3.5 не получается
В дискету — как нефиг делать. А вот на дискету — скорее всего нет.
Ну знаете, экстремальная оптимизация по одному параметру требует огромных расходов по другим параметрам. Запихать сериал в дискету не проблема и любой программист знает как это сделать, а вот чтобы извлечь за приемлемое время уже потребуется квантовый компьютер.
Это просто бизнес, детка, плюс культура потребления. Чтобы продолжать получать бабло, надо людям втюхивать очередную лажу, а для этого надо очень быстро придумывать никому ранее не нужные bells and whistles и убеждать людей, что им это нужно. Убеждать как минимум быстрее конкурентов, чтобы первыми сорвать сливки. В таких условиях на оптимизацию наплевать, главное - скорость. А там и производители железа выкатят что-то помощнее. В итоге все "продавцы/бизнесмены" в плюсе, и оптимизация никому из них не нужна, потому что не приносит вот вообще никакого профита.
Возможно, в условиях тотального дефицита каких-либо ресурсов для производства новых процов/памяти, но при этом дефицита, не влияющего на создание станков для производства "железа", такой оптимизацией и занимались бы. А в нынешнем мире чистогана - это только мечты. (Узкие отрасли, где ресурсы важны, я скипаю, ибо больно уж они узкие и специализированные, и там с оптимизацией всё ок).
Тут где-то был пост про то, что скоро нейронки начнут писать быстрее и лучше людей - ну так и закажите им улучшенные версии продуктов, и убейте этим конкурентов, если такие нейронки появятся
Вот бы ИИ научили оптимизировать сайты «на лету»! Сейчас ощутимая часть жизни — в Интернете, и ради сколь-нибудь отзывчивого браузера нужен неплохой компьютер, с четырьмя ядрами CPU, SSD и хотя бы 6 GB оперативки. А для сайта ещё четверть века назад хватало тридцатой доли этого.
Ну так 25 лет назад хорошим тоном было воткнуть весь контент страницы в 30 секунд работы 56 кбит модема.
Чуть выше писали:
надо людям втюхивать очередную лажу, а для этого надо очень быстро придумывать никому ранее не нужные bells and whistles и убеждать людей, что им это нужно.
Cкорее нейронку научать это делат еще лучше, чем заниматься оптимизацией.
Сейчас ощутимая часть жизни — в Интернете, и ради сколь-нибудь отзывчивого браузера нужен неплохой компьютер
Это может быть решено оптимизацией браузера в большинстве случаев. И ещё можно было бы заменить JavaScript более производительным языком, но это, к сожалению, совсем не реалистично.
хотя бы 6 GB оперативки
У меня с включенным браузером, слаком, телегой и тимс занято 15гб памяти :D
Нейронки не смогут писать лучше примеров на которых обучаются.
Кто то должен будет писать код для обучения нейронок и оценивать качество кода.
солидарен и простота Opengl(те люди кто его сделал просто гении, это же так просто нарисовать треугольник) в противовес Вулкана тому подтверждение, и не только по затрате кода на кубик/треугольник, но и в целом... даже на реддите было обсуждение, что если он выберет или выбрал бы Opengl
только что пришла идея, а есть такой язык, в котором упор на производительность и оптимизацию, вот интересно есть ли таковой )
любой низкоуровневый
Понимаю, что невежливо будет скидывать ссылку на двухчасовой видос, но вы, как человек увлекающийся, хотя бы посмотрите по двум таймкодам лекцию Константина Владимирова по теме (Проблемы OpenGL и Пример).
Конечно, при определенной кривизне рук можно и на Vulkan/DX12 рендер запилить так, что велосипед на OpenGL фпс выдавал бы больше по сравнению с ними, но это именно из-за кривизны рук.
смотрел. я наивно написал о самой сложности, и видел успешные примеры анимаций азиатские на директе и гл и вулкане, проблема только в том что на ГЛ банально проще эти моменты, которые в вулкане превратились совсем в другое, и это обросло уже железкой на 12 версии по всей видимости и на вулкане, ну я могу ошибаться
еще добавлю вашу ссылку этой great_resources
learn-vulkan/index.html и этой
на V-EZ +- примерная картинка ситуации (возможно уже обновилась)
а так конечно, жаль что ГЛ устаревает ( эх
только что пришла идея, а есть такой язык, в котором упор на производительность и оптимизацию, вот интересно есть ли таковой )
Человеческий. Оптимизации - они не про языки, а про архитектуру.
Пишу сейчас программу. С одной стороны, чуть заморочился и получил дистрибутив в 50 мегабайт вместо 200. Но с другой стороны, она в пике отжирает 3-6 Гб оперативки. 10 лет назад аналогичная по функциональности программа отжирала бы на порядок меньше, но не потому что сейчас руки кривые, а потом что тогда не нужно было ворочать битмапами в сотню мегапикселей.
Сейчас в привычном софте такой функционал, который кажется нам привычным, однако он требует ресурсов. Лёгким движением руки отправляем со смартфона видео в мессенджере... И за пару секунд оно конвертируется из 4к... За пару секунд...
Да мы ж сидим на Хабре, а тут нет-нет да кто-то выложит большие фото в PNG, иногда в 4К. А ещё нередко целая статья из картинок в этом формате. Народ жалуется? Нет, ну вот и всё, всё норм.
тогда не нужно было ворочать битмапами в сотню мегапикселей.
Кому было нужно покупали дорогие программы, у которых алгоритмы использовали диск вместо гигабайтов памяти. Абстрактный пример.
А что - индустрия чипов разве не упрётся в физические пределы размеров элементов чипа? Вот тогда и настанет этот дивный новый мир оптимизаций.
Она, похоже, уже упёрлась, где-то на уровне 10 нм.
Оптимизируется пока что только теплоотвод, сколько я понимаю. Потому что рост количества ядер и выделяемой теплоты дивными оптимизациями объяснить сложно.
Т.е. рано или поздно упрутся в предельную температуру, в кипятильник?
Так уже. Не зря начали пиарить жидкостные системы для масс и даже пробуют зайти на рынок датацентров. Воздух уже на грани окончания, больше тепла им не отвести. А без увеличения выделения тепла быстрее процессоры/видеокарты не сделать.
с теплом есть нюансы, по моим прикидкам лучший теплоотвод только в пещере, при условии корпуса из камня наверно,
жидкость имеет минус, она становится теплом а камень затеплить сложнее, плюс вода может закипеть, а камень не знаю мб просто рассыпется тут я не силён
ну и жидкость может попасть на плату типо того
Почему? Оно прекрасно масштабируется горизонтально, любой дата-центр или суперкомпьютер тому свидетельство.
Так уже упёрлась несколько поколений назад. Современные техпроцессы уже не уменьшают затворы транзисторов, но пытаются ворочать их в пространстве, чтобы плотнее поставить друг к дружке. Поэтому современные процессоры, хоть и несколько быстрее, но обычно и несколько горячее своих предшественников при максимальной нагрузке. А рост тепловыделения стараются компенсировать более интеллектуальным управлением включением/отключением вычислительных блоков.
Упёрлись. I/O по размерам не уменьшается толком, логику и кэш (ячейки памяти) пока ещё масштабируют на новых техпроцессах.
ну материалы только далее наверно, а так упёрлись наверно
Угумс, и на днях релизят новый Doom с неотключаемой трассировкой лучей, покупайте 5070+
Ну справедливости ради, все прошлые дум жрали на порядок меньше ресурсов, чем их современники сопоставимого качества.
покупайте 5070+
Там в требованиях более чем скромная GeForce RTX 2060 Super семилетней давности. То, что в 2025-м году новая игра наконец-то не идёт на GTX 1060, уже можно как-то пережить.
Может вы еще скажете, что автопроизводители не должны делать эти бесконечные никому не нужные ребрендинги каждые пару лет, стимулируя покупателя обновлять авто чаще, чем он действительно в этом нуждается? Что дальше, скажете производителям мобильников не выпускать новую версию линейки каждый год, даже если там буквально нечего придумывать всей матерой команде маркетологов а версию N от версии N+1 отличить можно лишь заглянув в настройки? Что дальше, откажемся от запланированного устаревания? От потребительства? Опасную вы игру затеяли. Ох, опасную. Это приведет к коллапсу рынков, за ними финансовых, а за ними и социальных институтов.
Разработчик, который пишет плохо оптимизированный, неустойчивый код, требующий много усилий на поддержку и все более абсурдные ресурсы для запуска - просто герой. Это то, в чем человечество остро нуждается. Он выполняет свой долг перед социумом и потомками, заботясь о непрерывной стимуляции и разрастании рынка и всего научно-технического прогресса.
Если недалекое начальство будет критиковать ваш говнокод, можете воспользоваться этим аргументом. Вакансий все равно пока в достатке.
Вот так, почти незаметно, маразм подкрадывается и великим, и тогда они от имени своего авторитета начинают выдавать на-гора простые, популярные и неправильные решения типа - нужно просто взять и начать все оптимизировать
В embedded programming часто код оптимизируется по максимуму.
Помнится был у меня проект когда в 16 Кб оперативки уживались OS+USB и сетевой стек+простой веб сервер+движок базы данных (правда поддерживающий предопределённые SELECT, но с JOIN-ами). Причём в процессе работы над проектом мне даже удалось оптимизировать код и освободить около 1 Кб памяти.
Но это был так скажем специфический случай...
Вспомнилась история одного фидошника, вот кажется нашёл - https://habr.com/ru/articles/27055/ :-)
лет 20 назад при разработке новой OS была задача время загрузки оптимизировать по возможности, поиграв с кластерами удалось уменьшить примерно на 30-40%, что было неплохо, заняло порядка 3 месяцев, вообще real time это почти всегда оптимизация, дело в US было, не знал что во Франции тоже embedded sw делают, что приятно,
16 KB это вероятно небольшое исполнительное устройство, типа термостата
Оптимизация... хм... ну так-то оно так - куча программ которые тупят непонятно почему, когда там функционал на уровне 90-х.
А с другой стороны - банальное численное решение уравнений Навье-Стокса которое нужно всем сводится обычно к решению СЛАУ. Ну и... чтобы там оптимизировать... только исходную постановку задачи.
Есть истина в его словах. Уже ПО, выполняющее относительно простые функции весит непомерно много. Как пример balenaEtcher или Kensington Works. Вот должно ПО для записи образов на флэшку или простого конфигурирования трекбола так много весить? Однозначно нет. И, как пример оптимизации, для первого есть аналог USBImager с аналогичным функционалом и на пару, если не тройку, порядков меньше по размеру.
Джон Кармак: мы все могли бы работать на старом компьютерном оборудовании, если бы оптимизация ПО была приоритетом