Комментарии 377
Действительно. Но кому это нужно? Оптимизация настолько дорого стоит что никто не заплатит и дешевле наращивать гигабайты.
Ну и например как не старайся, уместить сериал Карточный домик в дискету 3.5 не получается
Вы вряд ли поверите, но оптимизация во многих случаях не стоит вообще ничего, и более того, зачастую обходится дешевле, чем писать и сопровождать неоптимальный код. Просто... это тоже никому не нужно, т.к. до недавнего времени за софт платили столько, сколько попросят (да и сейчас многие по инерции всё ещё платят).
Вряд ли поверю потому что я было недели рабочего времени проводил над оптимизацией, никогда идеальный код не напишешь. Может ИИ будет писать идеально, не знаю, я - при всем моем желании и опыте - все равно делаю ошибки, хотя можно потратить больше времени и сделать лучше. В разы больше.
Оптимальный код - это не тот код, который вы неделю полировали, экономя килобайты и пару циклов. Оптимальный код, это код, в котором у вас не тянется стопицот тривиальных зависимостей, которые можно заменить на несколько своих строк. Это код, в котором у вас не компонуются чужие здоровенные компоненты, из которых вы потребляете 1% функционала. Код, в котором у вас нет вертикальной иерархии из вызовов микросервисов, и который не имеет в зависимостях исполняемую среду пайтона, хотя сам написан на чём-то другом.
Может ИИ будет писать идеально
ИИ, который учился на таком же коде, как и везде? Не та технология :)
Экономя килобайты? У нас 100 Gbps трафика, используется 500 CPU cores и 300 Gb ram. И никакого пайтона.
А 1% удаляется линковкой только до нужного функционала
Конечно идеально было бы пойти в asm и использование sse и других оптимизаций, но хоть и можно было бы попробовать - добро не дадут. Это сложно тестировать и не читаемо
А насколько эти cpu нагружены?)
Так это нагрузка в 500 ядер , где-то на 80% нагружены (т.е в реальности используется 625) из-за настройки скейла (над которой ещё работать надо но времени нет)
То есть загрузка каждого ядра 80%? Мне просто такая метрика не знакома - загрузка в ядрах
80% это обычно аварийное состояние системы
По-разному же бывает - сильно зависит от задач.
В рамках одного и того же проекта для части сервисов даже 25% может являться триггером для скейлинга (хвосты, не попадающие 99 перцентиль, могут резко портить всю картину и приводить к жалобам конечных пользователей).
А другая часть проекта, выполняющая какие-то фоновые джобы вполне может грузить процы в 100% и это будет нормально.
Если на ядре делается spin wait, то и 100% - нормально.
можно было бы попробовать - добро не дадут.
Ничего, у бизнеса потом на консультантов со стороны и деньги и добро найдется.
Это сложно тестировать и не читаемо
Не голый asm, а интринсики; не замена, а параллельная реализация горячих функций?
Дело в том, что с точки зрения бизнеса всё и так хорошо. Оптимизация понадобится когда-то потом.
И это на самом деле правильно - был бы я директором - меня бы не беспокоили каких то 500 ядер. Пока это работает, бюджет это осиливает, и всех всё устраивает. Технари не приоритет - надо продукт продавать.
И , конечно , бывают продукты, где скорость важна. Без неё ничего не продать. Но очень много таких - где оптимизация второстепенна. Например игры. Главное продать, даже если на 5090 лагает - потом доработают
Всё так. Если в случае бизнеса я вижу и понимаю другой mindset (отличное высказывание: "it's the cost of doing business"), то по играм у меня на уму другое: "лох -- не мамонт; лох не вымрет."
Ну самое главное в бизнесе говорить всякую ерунду с умным лицом и обещать райский сад
Так что Кармак может говорить что я со своего смартфона могу запускать проекты на Марс и ядерные бомбы, в то время как офис и киберпанк лагает на самых мощных компах.
Но на дискету всё не влезет
Но на дискету всё не влезет
Только, если эта дискета не квантовая.
Ну, в 60х - 70х запускались проекты на Луну и ядерные бомбы, так что думаю смартфон осилит. Проблема в том, что тогда было целью их запустить, а не продать оборудование для запуска.
Ну я конечно согласен с тем, что на оптимизацию зачастую кладут болт, однако и с тезисом про лунную программу не согласен, там подготовка программ к этому полету составила по времени годы, по затратам больше манхетонского проекта, а по ресурсам в том числе инженерным вообще молчу, ни одной компании не под силу такой мув повторить (+ не стоит забывать, что с надожностью ракет тех лет, были небольшие проблемки, хотя они есть и сегодня). А результат этой работы, можно и на смартфоне запустить, и полетит, споров нет.
И это на самом деле правильно - был бы я директором - меня бы не беспокоили каких то 500 ядер. Пока это работает, бюджет это осиливает, и всех всё устраивает.
А я, если был бы директором, задал бы себе сперва вопрос, какой запас прочности у нашего бизнеса, и хватит ли у нас времени и денег урезать прожорливость инфраструктуры до того, как бизнес сдохнет от кассового разрыва, если (или даже когда) наступит период, когда бюджет расходы на неё перестанет осиливать.
То то американские стартапы в топе всех рейтингов, а русские ну как-то держатся на плаву. Правильно приоритеты расставляют - инфраструктура всё ещё дешевле разработчиков, а сдохнет так сдохнет, все мы умрём рано или поздно, можно принять за аксиому. Но и русские есть очень интересные, у меня нет каких то приоритетов - статистика
То то американские стартапы в топе всех рейтингов
В топе всех рейтингов единицы стартапов. А те тысячи стартапов, которые сдохли, нам свои истории успеха не рассказывают.
Правильно приоритеты расставляют - инфраструктура всё ещё дешевле разработчиков
А это смотря сколько у вашей компании денег. Если вдруг на рынке неблагоприятная ситуация с продажами вашего продукта, вы можете приостановить разработку и уволить разработчиков, и ваш бизнес выживет. Но вы не сможете уволить инфраструктуру, потому что она и есть неотъемлемая часть продукта. Когда экономика на подъеме, денег в ИТ инвесторами вбухивается много, все живут хорошо. А вот когда наступают кризисы, умирают те, у кого постоянные издержки (в частности, инфраструктура) слишком высоки. Те же, кто её оптимизировал, те выживают
Те стартапы, которые сдохоли историй не рассказывают, но где-то есть тыщи рассказов от тех выживших стартапов, которые жили без разработчиков на хорошем оптимизированном коде и выжили.. где их почитать можно?
Ну и зачем нужен директор, главная задача которого ничего не трогать, главное, шобы не упало? Директора на мороз, на сэкономленные деньги, думаю, можно любую инфраструктуру уместить, хоть фейсбук с тыщей микросервисов... для пары клиентов то..
Правильно приоритеты расставляют - инфраструктура всё ещё дешевле разработчиков
Расходы на разработчика плюсь-минус единовременные(пусть, возможно, и большие и в несколько подходов), а инфраструктура все время эксплуатации этого куска кода расходов требует. Если эксплуатация достаточно длинная - то, по идее, рано или поздно станет дороже дополнительных расходов на разработку.
С развитием политики рефанда в большинстве сервисов-дистрибьюторов игр (Steam, EGS и проч), относить игры в разряд "продукты, где оптимизация второстепенна" будет все сложнее, т.к. все больше будет людей, которые приобретут, запустят, увидят корявую оптимизацию и вернут деньги. Это уже сейчас популярная схема на потестить
Люди делятся на тех, кому надо 120 ФПС и ультра графика, и тех кто может ради забавы поиграть с 30 ФПС на минималках. Оба купят игру за ту же цену. Или не купят ибо вылеты бесят всех ) я так SimCity 2 не купил, хотя очень хотел бы поиграть
все-таки Cities: Skylines 2 наверное
Точно, я и в первую не особо играл, но очень наслышан как о лучшем градостроителе
Сдаётся мне,
Workers & Resources должна быть хорошо соптимизирована,
потому как там ВСЁ зависит от ВСЕГО.
Ну, положа руку на сердце, все игры с экономикой, кроме Eve Online симулируют социализм в стиле СССР. Ибо мало есть любителей балансировать хаотический рыночек.
Еще есть игры серии X. Последняя X4 Foundation вышла недавно относительно. Но и в первых трех экономика симулируется весьма серъезно. Там можно понастроить фабрик и уронить цену ресурса почти в ноль. Можно уничтожить фабрики фракции в окресности, ресурса станет мало и цена взлетит в облака.
Мы тут вообще-то про оптимизацию движка говорим, при чём тут экономика?
Какие-то у вас фантазии про игры, где вы такое видели? Вы такой трюк выполните только один раз с одной игрой и на первый день продаж, а потом вы продадите 0 игр со второго дня, а имя вашей студии заклеймят и больше ничего покупать не будут
Экономя килобайты? У нас 100 Gbps трафика, используется 500 CPU cores и 300 Gb ram. И никакого пайтона.
Мне без дополнительных подробностей это ничего не говорит. Вы можете попасть в те немногочисленные технологические компании, где куча вычислительных мощностей делают эффективную полезную работу, или в те куда более многочисленные компании, где куча вычислительных мощностей в лучшем случае простаивает, а в худшем процентов на 90 загружена поддержкой инфраструктуры, т.е. является прожорливой вещью в себе.
Ничего не могу ответить, возможно для Вас datadog является никому не нужным мусором - кто читает эти логи, давайте все обойдемся без поддержки
А это точно не логи ради логов? Была когда-то вроде даже на хабре прохладная история о том как в пятницу вечером пытались понять почему падает производительность системы добавляя и добавляя новые логи. Пока в конечном итоге просто не грохнули их все и заработало как должно.
Так то судя по всему Кармак именно о том и говорит, что модульная микросервисная архитектура пораждает оверхеды (в том числе на логирование потому что как иначе разбираться что там сломалось) и без вот этого всего можно было бы жить гораздо эффективнее.
Конечно идеально было бы пойти в asm и использование sse и других оптимизаций, но хоть и можно было бы попробовать - добро не дадут. Это сложно тестировать и не читаемо
оптимизирующие компиляторы придумали еще лет 10-20 назад....
И как они, хорошо оптимизируют порядок независимых команд, чтобы выжать максимум из пайплайнового параллелизма современных процессоров в которых микроархитектура это в общем черный ящик да еще и такой, который от варианта к варианту и от версии к версии процессора меняется? Или они топорно меняю цикл на векторные инстрцкции везде где видят и на этом все?
Я могу поверить в хорошую оптимизацию, когда вендор поставляет свой компилятор под свое железо потому что у них (возможно) есть внтуренние доки и качественные эмуляторы для тестов. Но тогда возникают вопрос, а достаточно ли один вендор может выдедить ресурсов на разработку своего компилятора.
чтобы выжать максимум из пайплайнового параллелизма современных процессоров в которых микроархитектура это в общем черный ящик
В компиляторах есть достаточно подробные описания этих чёрных ящиков, например тут.
когда вендор поставляет свой компилятор под свое железо потому что у них (возможно) есть внтуренние доки и качественные эмуляторы для тестов.
Даже если вендор разрабатывает свой компилятор, ему всё равно выгодно вкладываться в оптимизации для своих процессоров в gcc/clang, поскольку большинство сидит на них - получаем эффективное увеличение производительности своих процессоров для конечных пользователей без изменения железа.
/me задумчиво смотрит на Питон
оптимизирующие компиляторы придумали еще лет 10-20 назад....
Когда я тридцать лет назад начинал программировать, мне рассказывали, что оптимизирующие компиляторы придумали лет десять назад.
но делать -О3 для кода, который был написан 3 стандарта языка и 5 ревизий компилятора тому назад, очень часто плохая идея :)
Конечно идеально было бы пойти в asm и использование sse и других оптимизаций, но хоть и можно было бы попробовать - добро не дадут.
Добро не дадут потому что понимают что у вас получится, и выяснится что все эти 500 кор нафиг не нужны. На закупках железа гигантские суммы осваиваются и пилятся.
К сожалению, это почти бесполезный подход в оптимизации бека. Фронт ещё можно оптимизировать, убрав зависимости, но на бек это повлияет слабо, так как проблемы очень часто чуть сложнее, а потери больше, чем от подгрузки пакета (хотя допускаю, что в вашем случае других проблем не встретилось и лишние пакеты правда были самым медленным звеном)
Ну пакеты бывают разные.... Например std\jsonи bytedance\sonic (я сейчас на го пишу) , но кто-то предпочитает вообще самому всё писать без лишних зависимостей и думает так лучше - его дело
Самая частая проблема бэка - инфраструктура, которая не соответствует его потребностям. Грубо говоря, компания имеет кубернетис с пачкой узлов, на каждом гроздь микросервисов, и для пущей гибкости они ещё и общаются между собой через сервис бас. Платит компания за это 10К в месяц, не считая зарплаты админа и девопса. При этом весь требуемый функционал с их текущей нагрузкой прекрасно помещается в одно приложение, работающее в одном инстансе, и ещё будет десятикратный запас для роста.
Покажите мне сервер с 500 ядер без кубернетисов . Оптимизация конечно ещё место имеет, но когда-то она заканчивается, а ресурсы на монолите заканчиваются быстрее.
Можно конечно гвозди забивать кувалдой. И не всем микросервисы подходят и накладные расходы имеют свою цену .
Но я не знаю как на одном сервере , пускай самом самом, обеспечить отказоустойчивость, масштабируемость и стрессоустойчивость. Максимум монолита есть максимум
Покажите мне сервер с 500 ядер без кубернетисов
Не покажу, но могу показать сервер с 16 ядрами без кубернетисов, который может заменить сервер с 500 ядрами с кубернетисом. Это - тоже оптимизация.
И не всем микросервисы подходят и накладные расходы имеют свою цену .
Фишка в том, что большинству микросервисы излишни. Может быть, даже подавляющему большинству. Если ваш проект, это нечто размером пусть не с Фейсбук, но хотя бы с Вайлдбериз, то микросервисы - ваша технология. Но сколько в стране проектов размером с Вайлдбериз? Сотни две наберётся? А сколько десятков тысяч проектов с микросервисами?
Хинт, монолиты прекрасно запускаются в контейнерах и точно также прекрасно скейлятся горизонтально. Даже огромные легаси монолиты с тысячами классов. Там у них другие проблемы, а не проблемы того как пятьсот ядер загрузить.
И никаких накладных расходов на rest\grpc :)
Только бывает и так, что нагрузка не из-за микросервисов и их оверхеда, и 500 ядер будет и в монолите 500 ядер, только со своими проблемами.
Хотя, думаю, если переписать один сервис, то можно обойтись и 50 ядрами. Там уже смотря как переписать и на чём.
Хотя этот бенефит микросервисов не используется - в основном пишут лишь на одном языке все сервисы, хотя из плюсов сервисного подхода - мол какой-то сервис можно написать на пхп, а какой-то на си, но нету настолько универсальных солдат
хотя из плюсов сервисного подхода - мол какой-то сервис можно написать на пхп, а какой-то на си
Это крупный минус сервисного подхода, потому что единая кодовая база, это тоже хороший такой бенефит. Если у вас сервис на другом языке, там будет дублирование кода (потому что вы не сможете использовать единые библиотеки, например, для аутентификации/авторизации), у вас будет раздувание необходимых компетенций в команде, т.к. вам нужно будет искать разработчиков с разными стеками.
Вот тут посмотрите )
Смотрю на 103е место и не понимаю, почему они 64 ядра процессора записали как 98 тыс ядер )
Во первых, на одной ноде кластера несколько сокетов, после чего мы кучку нодов втыкаем в стойку и располагаем кучку стоек в зале. Во вторых, ядра считаются и на CPU и на GPU. И всё это вместе можно использовать для решения одной задачи, цифры по производительности получаются на решении больших систем линейных уравнений.
Вот чисто потролить. На больше чам 500 ядер и без кубика: https://www.graphcore.ai/products/ipu :)
Вот на 1600 ядер и даже куберентисы можно запускать.
Фронт ещё можно оптимизировать, убрав зависимости
уменьшить количество запросов к бекенду. И не гонять данные туда сюда лишний раз. Я когда захожу на условный фейсбук на медленном интернет канале что вижу? А вижу пустую страницу с плейсхолдерами, куда потихоньку, лениво загружаются всякие данные в фоне. В результате - с одной стороны - я жду секунд 10, пока смогу пользоваться так называемым веб приложением. С другой - после этого могу хоть как-то им пользоваться, пока оставшиеся данные подгружаются (сделано плохо, из рук вон плохо). Но чтобы подождать пока загрузиться все - минут 5 пройдет. И на самом деле половина из всех загружаемых данных МУСОР или всякие трекеры моей активности. Ах, да, все сайты еще и кликстрим воруют, чуть ли не до движений мышки (!) М-да. Тот ли интернет это, который мы заслужили?
Без движений мышки разработчик не понимает, как починить проблему. Пишется это заранее, вдруг проблема будет.
то-то никто из саппорта мне никогда не может помочь - ни когда блокировка очередного финтех происходит, ни когда верификацию пройти не можешь, ни когда в убери оплата не проходит... Зато вот кликстрим зачем-то у ребят лежит в своем маленьком и уютном датасвампе... Реально индустрия куда-то не туда зашла
Вы видели хоть одного фронтендера, который использовал HeatMap движений мышки для поиска багов? А то я за 16 лет работы и из них 9 лет во фронтенде не видел ни разу. Вот Sentry видел, A/B тесты видел, асессоров видел, а HeatMap движений мышки не видел.
Судя по количеству презрительных к оптимизации откликов прямо тут, да =)
Веселее всего, если на питоне написан только скрипт для сборки, но питон почему-то всё равно в рантайм-зависимостях.
Оптимальный код, это код, в котором у вас не тянется стопицот тривиальных зависимостей, которые можно заменить на несколько своих строк.
Это ж что ж там нужно делать, чтобы главной проблемой оптимизации стали зависимости? Причём, не на клиентских машинах. Даже интересно увидеть.
Это ж что ж там нужно делать, чтобы главной проблемой оптимизации стали зависимости?
Не "главной проблемой", а "одной из проблем". Да, с зависимостями тоже всё плохо. У нас полным-полно даже вот таких штук:
Ну слабая стандартная библиотека в JS в сочетании со странным традициями тащить любую мелочь из npm у JS-разработчиков. А оптимизация-то тут причём? Если ту же маленькую. функцию написать самостоятельно, в соседнем файле, то она резко станет чистой, шелковистой и улучшать аппетит? :)
Я чаще видел обратное: когда вместо общепринятого, хорошо протестированного и оптимизированного решения пилят свой велосипед без большой на то надобности и времени на нормальную его доработку. Скорости работы это не способствует.
На одной из прошлых работ пришли заказчики - с ростом пользователей у них уже 2 раза апгрейдили сервер БД, но всё равно загрузка ЦПУ 100% и сервис ложится, хотя пользователей всего несколько тысяч. Только вычистив конструкции а-ля вложенные циклы с инсертом/аптейтом в таблицу по одной строчке там, где уместен batch insert/нормальный update, и переписав дважды-трижды вложенные селекты в нормальные join я почти вполовину снизил нагрузку. Да, мы не гугл в силиконовой долине, а шарашка петросяна в мухосранске, но и такую лапшу не надо писать. Так что оптимизация - она бывает разная. Кто-то экономит килобайты и пару циклов, кто-то убирает ненужные зависимости, а кто-то подтирает за нерадивыми погромистами.
Кто знает. Возможно если бы эти нерадивые погромисты писали сразу правильно и оптимизированно, то дело бытак ине дошло до реальных клиентов и прибыли.
В данном конкретном случае да, time-to-market был критичен (это была очередная "первая в мухосранске" местная крипто-биржа, как раз время бума всяких щиткойнов), но квалификации тех погромистов не хватало, чтобы потом сделать всё по-человечески. Всё, что они могли предпринять - сначала докупить проц/память, а потом и вовсе купить новый сервер помощнее. Как вы могли догадаться, из-за недостатка квалификации и спешки в разработке проблем там хватало. Как-то пользователи методом тыка узнали, что если быстро-быстро несколько раз нажать кнопку "перевести средства" до отрисовки следующей страницы приложения, то ВСЕ запросы будут обработаны и указанные средства переведутся столько раз, сколько успел нажать. Молва быстро распространилась среди юзверей и за ночь банковский счёт биржи опустел. Ситуацию спасло лишь то, что средства биржи хранились на разных счетах в разных банках и биржа вручную, в коде(!) настраивалась обращаться лишь к одному из банков. Часть средств вернули обзванивая каждого клиента и угрожая им судом, часть так и не вернули. В другой раз средства переводились в двойном объеме: выбор банка, как вы помните, был захардкожен (!) и для смены банка нужно было закомментировать ненужный сегмент кода и расскоментировать нужный, с нужным банком (!!!). Проявление проблем был лишь вопросом времени. Однажды один из погромистов просто забыл закоментировать ненужную часть и запрос на вывод денег отправлялся двум банкам. Поскольку днём нельзя перезагружать сервер, то и погромист закоммитил вечером, убедился, что пайплайн отработал без ошибок и довольный ушёл домой. Дальше - всё по старой схеме: молва пошла среди пользователей, за ночь опустошили на этот раз 2 счёта. Опять обзвон пользователей и пустые угрозы судом. Были и случаи утери коинов клиентов. Слава "первой криптобиржи в мухосранске" быстро сошла на нет и крипто-энтузиасты ушли к конкуренту, который хоть и запустился позже, но и таких факапов не допускал.
К чему это я - предварительная оптимизация это конечно плохо, и time-to-market это важно, но и хуяк-хуяк-в продакшн не надо делать.
Удвою. В 80% «оптимизаций» закладывается на этапе первичного написания кода. Главное не стесняться думать головой.
Но ведь не всегда удаётся угадать будущее продукта.
Есть одно правило, которое вот вообще никогда не подводит: если у вас нет данных о потребностях в масштабировании в будущем, значит, вам сейчас ничего дополнительного для масштабирования делать не нужно. Если вдруг ваш продукт окажется мегапопулярным, и вы будете наблюдать стабильный рост нагрузки, вот тогда вы сядете и будете работать над масштабируемостью. Благо, тогда ваш продукт уже будет работать, и у вас ещё и денег больше будет.
наблюдать стабильный рост нагрузки
Довольно распространенный миф, либо мне не повезло. Где я сейчас работаю, за несколько лет было несколько резких всплесков нагрузки. И каждый раз это было с ~0 до 100%.
Т.е. мы тоже кое-где срезали углы в угоду скорости разработки, в надежде, что постепенно будем улучшать узкие места. Но никакого in-between не было: 99% времени всё работает, нагрузка на инфру около 0, затем при всплеске популярности нагрузка 100% мгновенно.
Поэтому я теперь за разумную оптимизацию сразу, а не когда-нибудь потом.
Довольно распространенный миф, либо мне не повезло. Где я сейчас работаю, за несколько лет было несколько резких всплесков нагрузки. И каждый раз это было с ~0 до 100%.
С другой стороны - в мире реальных вещей отказ от обслуживания -- нормальная вещь. Ну вот не может завод больше кирпичей выпускать, свободных мощностей нет.
И ничего, живут, не строят заранее с возможностью масштабирования "А вдруг у нас со всей страны внезапно закупаться захочет".
Так что может быть все и привыкли и не смущались, если бы сервисы нашей индустрии так же делали.
С другой стороны - в мире реальных вещей отказ от обслуживания -- нормальная вещь. Ну вот не может завод больше кирпичей выпускать, свободных мощностей нет.
поддержу - вот весь этот QoS, рейт лимиты и прочее - это все надо имплементировать. Касательно айтишечки - почему-то есть миф, что мы можем скейлиться вечно. Ну, да - находясь в облаке - легко запустить +10 +100 +1000 реплик сервиса, чтобы узнать, что узкое место.... в системах хранения данных - например, в базе постгрес, в которой хранится самая ядерная часть данных бизнеса
И тут мне вспоминается история MMORPG EVE Online (она про космос) - разработчики описывали.
Сначала думали что подумаешь - GIL у Python - скорость процессоров будет расти. Когда оказалось что расти будет число ядер - пришлось править архитектуру, все что можно на внешние сервисы выносить с симуляторов мира, править игромеханику чтобы по возможности не было ситуаций когда один (пусть даже крутой) корабль запускает 666 дронов (а в ангаре еще 6666 лежат), и править логику чтобы по крайней мере если симулятору понятно что он не вывозит - тормозило у всех кто к нему подключен - одинаково, ну и питон для себя немного доработали чтобы можно было кучу "потоков" запускать. А параллельно всплыла еще проблема с тем что есть БД которая тоже тормозит и вот ее особо не поделишь (и начались игры c выносом БД на рамдиск).
Справились.
Ну тот же хабраеффект например. Хотя сегодня большинство продуктов закладывает масштабируемость изначально - и все равно даже кубернетисов бывает не хватает и всё упирается в какой-то лимит.
В любом случае от падения Гугла и Фейсбука пока ещё никто не умер
Довольно распространенный миф, либо мне не повезло. Где я сейчас работаю, за несколько лет было несколько резких всплесков нагрузки. И каждый раз это было с ~0 до 100%.
это органика. В смысле - у тебя пользовательская база обычно растет медленно и постоянно. Даешь рекламную кампанию - тогда прирост ускоряется. Простите, за тавтологию. А так параметры системы вполне стабильные. Утренние/вечерние часы. Выходные. Разве что - если ты в екоммерс - черная пятница может все сломать к чертям, но это УЖЕ существующие пользователи создают нагрузку в первую очередь. Выметая все с онлайн полок магазина. И к этому можно подготовиться.
Соглашусь лишь отчасти. Черная пятница да, утренние/вечерние часы да. Хотя во втором случае, разница в нагрузке (у нас) в рамках погрешности.
Вы как раз продолжаете подтверждать этот миф, либо у меня и правда слишком специфический кейс. Я говорю про рост, грубо говоря, в 1000 раз. Модель B2B2C, по типу хостинга. Сколько мы привлечем клиентов вполне прогнозируется. Но сколько наши клиенты привлекут своих клиентов на свои сервисы - сказать невозможно. И когда они это сделают, тоже.
Эта нагрузка всегда внезапна и кратковременна (по сути, как черная пятница, только в случайный момент времени).
Конечно, такие случаи всё равно примерно раз в год происходят, это не критично для нас, но неприятно. Выводы делаем, узкие места закрываем, но за год многое меняется.
Раньше было чаще, пока не стали хоть немного внимания уделять базовой оптимизации. Это, конечно, ничего не доказывает и не является статистикой.
О, я помню распродажи в мазеркере, когда одна страница сайта открывалась по несколько минут
Где я сейчас работаю, за несколько лет было несколько резких всплесков нагрузки. И каждый раз это было с ~0 до 100%.
Да, такое везде есть. В черную пятницу и перед НГ. Если на Западе, ещё перед Пасхой и Рождеством. Как раз это можно запланировать изначально, например, подняв ещё пару инстансов в облаке.
У меня есть простое правило. Не рефактори с первого раза. Если в легаси код заходишь, чтобы починить баг раз в год, то и фиг с тем как там код накидан, ты же быстро разобрался, пусть и с матами. Если туда ныряешь уже второй раз,то стоит подумать, как сократить себе работу на третий раз.
Особеннно это полезно при прототипировании. Прототип можно писать очень грязно, но быстро, потому что по итогам его презентации узнаёшь очень много нового. И целевая система либо будет спокойно работать ещё несколько лет и на этом говнокоде, потому что он взял и закрыл проблему. Либо всё равно придётся все переписать с учётом того, куда система будет двигаться. Плюс говнокода - что его не жалко, потому что на него было потрачено очень мало времени.
Именно это я имею в виду.
А некоторые в неё, увы, едят...
«это слишком сложно» - обычно слышу я в ответ
Оптимизация бывает разной. Часто оказывается, что максимально производительный код - это часто очень лютое Г, которое сильно заточено под особенности железа, которое дорого писать и дорого поддерживать, но которое позволяет выжать всё, что возможно.
Например, если речь про 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/
На практике "оптимальность" кода - не универсальное понятие, а зависит от требований к нему (коду)
Оптимальность кода зависит от требований весьма опосредованно. Я именно это и написал - если не иметь в виду какие-то специфические расчётные применения, т.е. когда эти самые требования есть, по скорости, по памяти, по алгоритмам. Практически во всех остальных случаях нет никаких требований к коду, кроме того, чтобы он выполнял поставленную задачу. А вот оптимальный он или нет, это уже его качественная характеристика, ортогональная требованиям.
Всё чаще прихожу к тому, что если нужна максимальная производительность некоторых методов, то этот код можно оставить его в виде чёрного ящика, может в отдельном файле. Пусть он использует кучу грязных приёмчиков, плохо читаем (комменты никто не отменял), но работает максимально быстро и выжимает всё из железа. Ассемблер - крайняя мера, но тоже позволяет сильно ускориться, оптимизаторы компиляторов обычно не дотягивают.
Вы в крайности уходите. Чаще все банальнее. Например, на той же Java Hibernate генерит n +1 SQL запрос при выборе коллекции объектов. Т.е. при вытягивании коллекции из 100 объектов, будет 101 запрос к БД. Исправляется вообще не сложно, гуглится за пять минут. И знали бы вы сколько раз я такое видел в проектах.
Какая интересная позиция. Каждый второй программист не может ничего оптимизировать, потому что не умеет (кроме совсем уж тривиальных вещей). Каждый второй менеджер не знает, что делать, кроме как попросить «тормозит, сделай что-нибудь». И каждый первый пользователь слишком далеко от разработки, что бы сообщить о проблеме и о том, что она важна для него.
вы сами себе противоречите - "оптимизация бесплатная и дешевле неоптимального кода", но "это никому не нужно"
Не могли бы вы перечислить хотя бы несколько случаев?
Нет. Большая часть неоптимальности в не бесплатных абстракциях: фреймворки на фреймворках, завернутые библиотеки и эмуляцию. Вот, например, приложения на электроне. Тормозят, потому что это целый браузер для каждого приложения, интерпретирующий джаваскрипт. Завести сюда оптимизацию - это надо разрабатывать отдельно веб приложение и нативные приложения под каждую систему. Это нужно в 4 раза раздуть штат, набрать специалистов по нескольким языкам программирования, поддерживать похожий код в 4-ех местах, инфрастурктуру под это все и много много отладки багов, потому что, например, только на этой условной версии MacOs что-то отваливается в приложении.
И тоже самое в играх. Можно взять готовый unreal engine и не разбрабатывать огромной командой десять лет свой движок. Можно впендюрить люмены и наниты и не расставлять освещение руками во всех уровнях, сэкономив человеко-годы работы и зарплаты. Да, это будет тормозить на не топовых видюхах из последнего поколения, но с ИИ дорисовкой кадров и растяжением картинки - люди хавают.
Так что, нет, большая часть оптимизации совсем не бесплатна.
уместить сериал Карточный домик в дискету 3.5 не получится
Карточный домик может и нет, но очень крутые вещи умудряются вместить в 64 кб
Да, оптимизация просто так не даётся. И чем она выше, тем сложнее разрабатывать. Но есть ощущение, что сейчас много где достаточно применить 20% усилий, чтобы получить прирост на 80%. Но на это забивают
очень крутые вещи умудряются вместить в 64 кб
Проблема в том, что это, своего рода, «подгонка задачи под ответ». То есть не получится создать произвольную анимацию, а только найти некий компактный алгоритм, который бы выдавал картинку, подходящую под сценарий. Притом во многих случаях экономия на размере бинарника приводит к несоразмерным требованиям к производительности.
как не старайся, уместить сериал Карточный домик в дискету 3.5 не получается
В дискету — как нефиг делать. А вот на дискету — скорее всего нет.
На дискету можно положить BlueRay, а вот в дискету не влезет
При этом записать на дискету (поверх пустого пространства).
Но я конечно не граммарнацы, как вам угодно, пускай будет на
На дискету можно положить BlueRay
Если смотреть со стороны габаритов, то в квадрат 90×90 миллиметров без труда поместится современный терабайтный SSD-диск в форм-факторе M.2. По толщине вроде бы тоже проходим. Хватит этого на ваш любимый сериал?
Мне вспомнилась технология "кассета адаптер для магнитолы aux" когда в магнитолу вставляется нечто способное получать звук с мини-джека и отдавать электромагнитные колебания на магнитную головку так что с точки зрения магнитолы это как будто обычная кассета. У автора комментария нет требований чтобы "карточный домик" воспроизводился с дискеты в реальном времени.
Да и мультимедиа - чуть ли не единственная причина иметь дома современный (не путать с мощным) компьютером. Ну вот захотелось мне посмотреть видео 4k h.265 - 4е поколение Интел без фризов не тянет даже с разгоном, 11 поколение играет и даже не греется.
Чего? Н265 в 4к даже копеечные телеприставки на армах тянут
Значит они - не старое компьютерное оборудование, там есть аппаратное ускорение довольно свежего кодека. Речь шла про эту трилогию, возможно повлияло то что там 10бит цвета, или ещё то что я её смотрел на экране FullHD, то есть у видеопроцессора была одна дополнительная операция - даунскейл. Я редко смотрю фильмы и даже не пробовал смотреть никаких других видеороликов в таком же разрешении, может быть другие пойдут как раз без тормозов.
Ну знаете, экстремальная оптимизация по одному параметру требует огромных расходов по другим параметрам. Запихать сериал в дискету не проблема и любой программист знает как это сделать, а вот чтобы извлечь за приемлемое время уже потребуется квантовый компьютер.
уместить сериал Карточный домик в дискету 3.5
Все зависит от формата, и выбранной степени сжатия. Например, краткое эссе в текстовом виде - вполне даже поместится.
Не то что "краткое эссе", все диалоги и описания сцен поместятся.
Тексты на человеческих языках в алфавитной записи сжимаются примерно в три раза. На одну дискету можно упаковать все четыре тома "Война и Мир" Л. Толстого (4.1 MБ оригинального текста).
Вы говорите про обычное архивирование. На самом деле сжатие можно оптимизировать путем составления обратного индекса: справочника слов и позиций в тексте. Позиций так же можно оптимизировать через математическое кодирование. Можно оптимизировать и кодировку текста, например, если текст хранится в кодировке UTF-8, то привести к однобайтовой + так как у нас ограниченный алфавит, то можно кодировать несколько символов в одном байте. Ну и на последок шлифануть это каким нибудь 7z или написать свой архиватор. Вот кстати хороший пример, что оптимизировать можно сколько угодно, только смысла в этом нет.
https://www.asciimation.co.nz/index.php
Не совсем Карточный домик, Звёздные Войны эпизод 4, но тем не менее.
Без браузера с телнетом тоже работает, towel.blinkenlights.nl.
Ещё:
Операции с архивами
Компиляция кода
Прогон тестов
Вычесления для инженерных проектов
Работа с графикой
Реалистичная физика с миллионом объектов (игры/наука)
Скорость бекапп/синхронизации/сохранения данных
Бюрократия
Гигантское число подключений к серверам
Да, для повседневной жизни, браузер там полестать, документы подредачить, видео посмотреть хватит и 1гб оперативки (Мин потребления полноценного линя - 200мб (с графикой 350мб) и меньше), для Вин приложений, как офис, wine оказывается иногда даже быстрее нативной винды.
А вот для игр/работы нужно уже что-то куда мощнее, и есть фундаментальные ограничения, что и не оптемезируешь
(Ну и ещё миллионы не оптемизированных приложений)
Смотря каких игр, на 1 Гб тоже играли в игры :) Старкрафт, первая и вторая Халфа, серия Фоллаут, серия Герои меча и магии, тысячи их.
1 Гб, тоже мне!
А в космосим сыграть смогли бы
На сорок восемь КИЛОбайт?
Android стал тормозным дермищем ¯_(ツ)_/¯
Смеялся с новости что в Windows 11 тормозит кнопка Пуск так как это React Native приложение - 30%-70% нагрузка на ядро процессора
Ну и например как не старайся, уместить сериал Карточный домик в дискету 3.5 не получается
Вы уверены ?
Пишем максимально подробный сценарий и описание одежды и прочего реквизита.
У получателя запускаем локально какой-нибудь SoraШедеврум v42, и все рендерится у получателя прямо в смарт-очках.
Да - тут размениваем емкость канала связи на объем "словаря для распаковки" и требуемую "вычислительную мощность для распаковки".
А что, такая нейросетка вместе со своей базой знаний на дискету уместится?
А про размер сетки разговора не было :). И сетку не надо каждый раз новую.
Ну так видеоплеер и ОС у вас тоже не качается каждый раз.
Тогда это не «распаковка», а воссоздание заново. Если у пользователя другой «плеер» с другой нейросеткой, то и фильм он другой увидит.
Даёшь нейропересказы и нейроизложения в массы! Прямо как в советской средней школе на уроке русского языка и литературы.
Смех смехом, но в летнем лагере мы так друг другу пересказывали фильмы. Я как-то пересказывал "Болотная тварь", а кент - "Индиана джонс и храм судьбы". Да, я пересказ слышал до того, как смог посмотреть лично. Друг ничего не наврал и довольно таки точно пересказал.
В прицнипе можно для распаковки свою театральную труппу использовать, лет триста назад такое практиковалось. Но сейчас да, AI должен справиться.
Раньше каждый для распаковки свою внутричерепную нейросетку использовал, марки «Воображение». А файл «Книга» назывался.
А ещё раньше такие файлы только голосом передавались )
У меня нет уверенности что полное описание в достаточных подробностях чтобы сериал воспроизвелся "как был" уместится в дискету. Там промт на одну сцену будет несколько страниц. Берите проще - вместо серий передавайте тройку хэшей файлов. А потом перебирайте брутфорсом содержимое пока все хэши не совпадут.
С помощью фрактальных алгоритмов сжать все сезоны на дискету реально, но не выполнимо. Сжатие будет длиться дольше, чем просмотр.
Это да, но каком в свое время умудрились RE2 запихать полностью в 64мб картридж от N64, когда на PS1 он занимал 2 CD-ROM, при этом ничего не вырезая.
А демка 3д шутера .kkrieger, на 96кб, так вообще до сих пор "АналоГовнет"
Оптимизацию мог бы реализовать ИИ. Сжать приложение в ASM, переписать зависимости, оставив только необходимое. После чего человек уже такой код не сможет изменить, что также к лучшему.
Здесь уместно вспомнить интерпретирующую систему для ЭВМ М-20, М-220. Вот кто были настоящими кудесниками программирования:
М.Р. Шура-Бура тщательно следил за экономией памяти и тактов
работы М-20, поскольку библиотечная система навсегда отнимала у счетных
задач часть оперативной памяти и обязана была работать быстро. Когда
система задышала, стало ясно, что ИС-1, обладавшая многими возможностями,
тратит лишние такты и занимает много памяти. Поэтому, отказавшись от
излишнего универсализма ИС-1 и виртуозно используя систему команд М-20,
М.Р. Шура-Бура (буквально за одно воскресенье, чуть меньше суток) написал
новую интерпретирующую систему ИС-2 [1]. Это была жемчужина
программирования в кодах ЭВМ!
И в первую очередь сам М.Р. Шура-Бура, с которым мне посчастливилось пересекаться во время учёбы.
Это просто бизнес, детка, плюс культура потребления. Чтобы продолжать получать бабло, надо людям втюхивать очередную лажу, а для этого надо очень быстро придумывать никому ранее не нужные bells and whistles и убеждать людей, что им это нужно. Убеждать как минимум быстрее конкурентов, чтобы первыми сорвать сливки. В таких условиях на оптимизацию наплевать, главное - скорость. А там и производители железа выкатят что-то помощнее. В итоге все "продавцы/бизнесмены" в плюсе, и оптимизация никому из них не нужна, потому что не приносит вот вообще никакого профита.
Возможно, в условиях тотального дефицита каких-либо ресурсов для производства новых процов/памяти, но при этом дефицита, не влияющего на создание станков для производства "железа", такой оптимизацией и занимались бы. А в нынешнем мире чистогана - это только мечты. (Узкие отрасли, где ресурсы важны, я скипаю, ибо больно уж они узкие и специализированные, и там с оптимизацией всё ок).
Тут где-то был пост про то, что скоро нейронки начнут писать быстрее и лучше людей - ну так и закажите им улучшенные версии продуктов, и убейте этим конкурентов, если такие нейронки появятся
Вот бы ИИ научили оптимизировать сайты «на лету»! Сейчас ощутимая часть жизни — в Интернете, и ради сколь-нибудь отзывчивого браузера нужен неплохой компьютер, с четырьмя ядрами CPU, SSD и хотя бы 6 GB оперативки. А для сайта ещё четверть века назад хватало тридцатой доли этого.
Ну так 25 лет назад хорошим тоном было воткнуть весь контент страницы в 30 секунд работы 56 кбит модема.
Чуть выше писали:
надо людям втюхивать очередную лажу, а для этого надо очень быстро придумывать никому ранее не нужные bells and whistles и убеждать людей, что им это нужно.
Cкорее нейронку научать это делат еще лучше, чем заниматься оптимизацией.
Сейчас ощутимая часть жизни — в Интернете, и ради сколь-нибудь отзывчивого браузера нужен неплохой компьютер
Это может быть решено оптимизацией браузера в большинстве случаев. И ещё можно было бы заменить JavaScript более производительным языком, но это, к сожалению, совсем не реалистично.
Там часто и DOM ужасно раздут, с кучей безымянных блоков, вложенных друг во друга.
Проблема не столько в JS - современные реализации которого весьма быстрые, сколько в том, что у типичных смузихлебов-фронтэндеров вечно фреймворк поверх фреймворка, который поверх еще одного фреймворка. И еще и вечно гордые собой - мы умные и современные, вон, сколько баззвордов знаем.
хотя бы 6 GB оперативки
У меня с включенным браузером, слаком, телегой и тимс занято 15гб памяти :D
С грустью пытается подсчитать, сколько это вагонов БК-шек...
У человека браузер, браузер, браузер и браузер занимает 15гб. Уменьшить количество браузеров, убрать все смайлики, убрать поддержку всех не ascii/ansi символов и заменить 3 последних браузера на xmpp/irc, заодно понизить битность архитектуры до 8бит - Джон Кармак будет счастлив!
Сколько, интересно, придётся отдать поставщикам LLM для того чтобы так и сделать?
Возврат к однобайтным кодировкам… Как же их не хватает. Молодёжь-то по одному взгдяду уже не умеет отличить, открылось у них cp1251 в utf8, или koi8-r в cp1251. В firefox ручное открытие в нужной кодировке вообще убрали.
Зачем? Всеобщий utf8 это лучшее что произошло с кодировками.
Кодировка с переменной длиной символа это грустно, почти как в анекдоте про имперскую систему мер.
Это про оптимизацию которая работает на практике. Мы в комментах статьи про оптимизацию.
Дык и я про нее, родимую. Когда символ занимает фиксированное число байт, код, например, для индексирования и определения длины значительно проще, читабельнее и быстрее, так что UTF-32 мне нравится больше, от однобайтовых кодировок у меня детская травма и комментарии в коде только на английском. Правда, тут можно сорваться в очередной спор "память или процессор".
Практика показала что длину строки дешевле всего передавать рядом с самой строкой. Не надо оптимизировать функцию подсчета длины.
А вот рендеринг и объем данных оптимизировать надо. Их простым хаком не улучшить.
Как UTF-8 ускоряет рендеринг? Да и с объемом данных очень спорно:
UTF-8 часто не однобайтовый (первый байт ASCII, два байта - европейские алфавиты, три байта - азиатские алфавиты, четыре
чтобы ими править- эмоджи и прочий мусор)текст не является основной нагрузкой на сеть, так что условное удвоение веса текста мало на что повлияет. Насколько я помню, отправка пустого сообщения в Telegram сжигает около 10кБайт мобильного интернета :)
Зато поделить фут на 2, 3, 4 и 6 — это любой ду местный плотник сможет.
Очень сильно подозреваю что задача сведется к выкидыванию не нужного пользователю хлама нейронкой у клиента. Adblock AI Edition. что даст 90%+ результата.
А разработчики сайтов будут писать на хабре статьи как использовать фокусы вроде https://habr.com/ru/articles/909188/ чтобы ОченьВажныйКод блочился (ну или продвигать запрет таких средств блокировки или технические методы противодействия).
Нейронки не смогут писать лучше примеров на которых обучаются.
Кто то должен будет писать код для обучения нейронок и оценивать качество кода.
Ошибка. Reinforcement learning не подразумевает обязательно «кого-то», кто пишет очень хорошие примеры. Мы убедились в играх, что обогнать человека чемпиона не так уж сложно. Обогнать человека чемпиона в программировании тоже возможно.
А что это за чемпион в программировании?
В играх есть чёткие правила и цель. В программировании такого чаще всего нет.
И в программировании есть - корректность и скорость исполнения
Исполнения чего?
Желаний заказчика, само собой. Идет мощнейшая атака продаванов вложившихся в АИ. Есть бюджет на рекламу, она прет. Год, два останутся нужные продукты на аи, пена схлынет.
Как правило, не бывает идеального кода для сложных задач.
Либо код жрет CPU, и не расходует память, но работает медленно, либо память уходит вагонами, а процессор отдыхает.
Почти всегда один параметр вступает в противоречие с другим и нужно балансировать. Поэтому лучший код для одних требований может оказаться худшим для других.
У меня только что закончилась 12 летняя эпопея поддержки кастомного поисковика использующего люсин, который плавно перерос в агрегатор поисковиков на Люсине опять же, и не только на люсин.
Начал писать записки, аккумулирующий мой опыт работы с клиентами. Для интервью, а может на Хабре опубликую, если силы будут отполировать текст.
К примеру, хорошо ли использовать кластер солр или эластик с кучей мелких нодов , шардов и репликацией? Вроде бы да, особенно если в облаке. А если клиент требует join? И не вырожденный случай со связыванием небольшой коллекции а полноценный, на пару сотен лямов записей? Тогда выкатываем вертикально масштабированный люсин, еще и с композитным индексом на разных дисках, чего ни солр, ни эластик делать не умеют.
И масштабируем копированием, как в 18 веке. И нормально работает "он премисис".
Аи не всемогущ. Это не аи умный, это человеков отупляют.
Это условно. Какую бы метрику вы ни задали, её можно оптимизировать (научить нейронку её повышать)
Какую, например? Я ни одной универсальной метрики не могу придумать.
Так надо выбирать под конкретную задачу - скажем, размер кода или среднее время исполнения на наборе бенчмарков.
У нас задача "обогнать человека чемпиона в программировании". Какие тут метрики нужно оптимизировать?
Ставим задачу, получаем код от человека и AI, сравниваем по вышеприведённым критериям.
солидарен и простота Opengl(те люди кто его сделал просто гении, это же так просто нарисовать треугольник) в противовес Вулкана тому подтверждение, и не только по затрате кода на кубик/треугольник, но и в целом... даже на реддите было обсуждение, что если он выберет или выбрал бы Opengl
только что пришла идея, а есть такой язык, в котором упор на производительность и оптимизацию, вот интересно есть ли таковой )
любой низкоуровневый
Понимаю, что невежливо будет скидывать ссылку на двухчасовой видос, но вы, как человек увлекающийся, хотя бы посмотрите по двум таймкодам лекцию Константина Владимирова по теме (Проблемы OpenGL и Пример).
Конечно, при определенной кривизне рук можно и на Vulkan/DX12 рендер запилить так, что велосипед на OpenGL фпс выдавал бы больше по сравнению с ними, но это именно из-за кривизны рук.
смотрел. я наивно написал о самой сложности, и видел успешные примеры анимаций азиатские на директе и гл и вулкане, проблема только в том что на ГЛ банально проще эти моменты, которые в вулкане превратились совсем в другое, и это обросло уже железкой на 12 версии по всей видимости и на вулкане, ну я могу ошибаться
еще добавлю вашу ссылку этой great_resources
learn-vulkan/index.html и этой
на V-EZ +- примерная картинка ситуации (возможно уже обновилась)
а так конечно, жаль что ГЛ устаревает ( эх
только что пришла идея, а есть такой язык, в котором упор на производительность и оптимизацию, вот интересно есть ли таковой )
Человеческий. Оптимизации - они не про языки, а про архитектуру.
OpenGL прост наверху, а в недрах как раз мрак (устаревшие абстракции плохо ложатся на современное железо). Metal с Vulkan-ом сделали в том числе для того, чтобы этот мрак можно было выкинуть.
А может для игр не нужно вообще видеокарт? Можно ввести стандарт 1080 и отображать динамические растовые картинки )
Пишу сейчас программу. С одной стороны, чуть заморочился и получил дистрибутив в 50 мегабайт вместо 200. Но с другой стороны, она в пике отжирает 3-6 Гб оперативки. 10 лет назад аналогичная по функциональности программа отжирала бы на порядок меньше, но не потому что сейчас руки кривые, а потом что тогда не нужно было ворочать битмапами в сотню мегапикселей.
Сейчас в привычном софте такой функционал, который кажется нам привычным, однако он требует ресурсов. Лёгким движением руки отправляем со смартфона видео в мессенджере... И за пару секунд оно конвертируется из 4к... За пару секунд...
Да мы ж сидим на Хабре, а тут нет-нет да кто-то выложит большие фото в PNG, иногда в 4К. А ещё нередко целая статья из картинок в этом формате. Народ жалуется? Нет, ну вот и всё, всё норм.
Хабр даже во времена своего пика был достаточно отсталым в техническом плане сайтом, если честно.
А сейчас люди привыкли что сайты отрезайсят картинки в нужное разрешение, вот и заливают не парясь.
Я не жалуюсь, я смотрю с телефона с плохим инетом, что кпдв тормозит и сразу минус ставлю)
Не всё норм на самом деле. Я, к примеру, только что узнала, что при загрузке сюда чего-либо надо париться и самостоятельно менять размер картинки. Мне это просто в голову не пришло бы, потому что это даже сайты из нулевых умели
тогда не нужно было ворочать битмапами в сотню мегапикселей.
Кому было нужно покупали дорогие программы, у которых алгоритмы использовали диск вместо гигабайтов памяти. Абстрактный пример.
10 лет назад аналогичная по функциональности программа отжирала бы на порядок меньше
Ну так 10 лет назад и никому в голову не приходило засунуть браузер в приложение, чтобы сделать UI с несколькими кнопками. Браузер, Карл! Сейчас норм, берем electron и вжух-вжух.
Уже рекурсия пошла. Хотел на Дебиан 12 поставить Мидори, легковесный браузер, который в предыдущих версиях Дебиана ставил. А нету в репозитории. Что случилось? Оказывается, его переписали на электроне и смысл в нём пропал.
Мы засунули браузер в твой браузер, чтобы ты мог браузить, пока браузишь, Карл!
Вы зря так думаете. У Microsoft в начале 2000-х (уже более 20 лет назад) в Visual Studio были визарды, написанные на HTML и работавшие через встроенный компонент IE. Ещё чуть раньше, с выходом IE 5 (1999) появилась поддержка HTML Application (HTA).
Также, если мне не изменяет память, в игре NHL 2003 главное меню тоже работало через браузер. На моей 98 оно криво отображалось без обновления браузера, при перехоже по меню были слышны характерные щелчки IE. 3D-игра, Карл!
Что-то более нативное вроде WinUI работает ничуть не лучше.
В большинстве гуевых приложений узкое место - сам уй фреймворк, и разработчик приложения ничего с этим сделать не может. А использовать какой-нибудь древний фреймворк из 90-х который работает быстрее не выйдет - потому что больше не поддерживается, не собирается, а если и работает то нет базовой функциональности вроде hidpi и т.п. Или он написан на C и нормальных оберток для других языков нет.
А что - индустрия чипов разве не упрётся в физические пределы размеров элементов чипа? Вот тогда и настанет этот дивный новый мир оптимизаций.
Она, похоже, уже упёрлась, где-то на уровне 10 нм.
Оптимизируется пока что только теплоотвод, сколько я понимаю. Потому что рост количества ядер и выделяемой теплоты дивными оптимизациями объяснить сложно.
Т.е. рано или поздно упрутся в предельную температуру, в кипятильник?
Так уже. Не зря начали пиарить жидкостные системы для масс и даже пробуют зайти на рынок датацентров. Воздух уже на грани окончания, больше тепла им не отвести. А без увеличения выделения тепла быстрее процессоры/видеокарты не сделать.
Почему? Оно прекрасно масштабируется горизонтально, любой дата-центр или суперкомпьютер тому свидетельство.
Разве это не рост в многопроцессорность? Т.е. в этом направлении уже Закон Амдала передаёт привет.
Да и кто захочет у себя дома держать датацентр?
А кто сейчас хочет держать киловаттный "утюг"?
Это, похоже, никого не заботит. Когда читаю обзоры новых процессоров, то не вижу в них сокрушений по поводу большого расхода электричества. Про перегрев — сокрушаются. Про необходимость покупать дорогую систему охлаждения — грустят. А вот про наматываемое на счётчике сожалений не видел никогда. То есть это не проблема.
Оптимизируется паразитная ёмкость затворов транзисторов, по сути. Потому что основные энергозатраты в нынешних процессорах - именно на перезаряд этих емкостей.
Так уже упёрлась несколько поколений назад. Современные техпроцессы уже не уменьшают затворы транзисторов, но пытаются ворочать их в пространстве, чтобы плотнее поставить друг к дружке. Поэтому современные процессоры, хоть и несколько быстрее, но обычно и несколько горячее своих предшественников при максимальной нагрузке. А рост тепловыделения стараются компенсировать более интеллектуальным управлением включением/отключением вычислительных блоков.
Упёрлись. I/O по размерам не уменьшается толком, логику и кэш (ячейки памяти) пока ещё масштабируют на новых техпроцессах.
ну материалы только далее наверно, а так упёрлись наверно
Угумс, и на днях релизят новый Doom с неотключаемой трассировкой лучей, покупайте 5070+
Ну справедливости ради, все прошлые дум жрали на порядок меньше ресурсов, чем их современники сопоставимого качества.
А про прошлые речи не идет.
Ну не все, да и Кармака в составе разработки уже давно увы нет :)
Разве не все? Почему то у меня в памяти гораздо больший ФПС дума по сравнению с шутерами современниками.
А какие сравнимые по качеству шутеры современники были у первого дума?
Он был не один, и все игры Id soft - Quake, WolfenStein имели фпс примерно вдвое лучше одноклассников =)
Так всё таки что сравнимое не от id было во времена первых Wolfenstein/Doom? Вспоминаются разве что Ultima Underworld и System Shock, но это другие жанры.
Heretic, Marathon, Блейк и его клоны на вольфовском движке. Ультима UW опять же
Всё таки не вижу тут сторонних шутеров, выходивших в первой половине 90х одновременно с играми от id, а не созданными после на волне их популярности. Насколько я вижу, что то сравнимое и не вторичное появилось позже - Duke 3D, Unreal, Half Life и т.д.
Heretic/Hexen это всё тот-же Doom под капотом, только для Hexen знатно доработанный
Я брал времена последних дум, а не классики. Во времена классики ничего в конкурентах не было, а то, что было работало так же потому, что один в один повторяло алгоритмы.
Если взять поновее - то Doom 3 был явно требовательнее к ресурсам, чем Half Life 2.
Я уже не помню, но если глянуть требования в инете, минималка у второй Халфы пожирнее будет, чем у третьего дума. 512Мб ОЗУ против 384Мб, шейдеры 2.0 против 1.1
Это точно про оригинальный релиз? Я HL2 проходил на Geforce MX440; памяти таки было 640 метров (так вышло), но это точно было с большим запасом. Тут пишут про 256 Mb и DX7.
покупайте 5070+
Там в требованиях более чем скромная GeForce RTX 2060 Super семилетней давности. То, что в 2025-м году новая игра наконец-то не идёт на GTX 1060, уже можно как-то пережить.
На 1080 ti сносно идёт все что угодно в fullHD, поэтому я считаю неотключаемые лучи вредительством.
Неотключаемые лучи - это не для того, чтобы заставить вас купить новую карточку, а для удешевления разработки. На лучах освещение писать намного проще. А то, что относительно небольшой процент геймеров останется "за бортом", ну ок. Сколько там людей сидит на карточках, которые поднатужившись могли бы потянуть игру, но без лучей не смогут? По сути, только владельцы 1080 и 1070. Вон они на графике, суммарно 2% от пользователей Steam:
А то, что относительно небольшой процент геймеров останется "за бортом", ну ок.
На лучах освещение писать намного проще.
Кто мешает для бедных нарисовать геометрию с текстурами и оставить освещение на уровне, который даёт голый Vulkan без шейдеров?
Например, желание удерживать некоторый минимальный уровень качества картинки. Вы же обратите внимание на современные игры, они в массе своей на минималках смотрятся вполне себе достойно, не так чтобы сильно отличаясь от "ультра". Было бы странно, если бы Дум, который всегда преподносился как технологический лидер, выглядел бы на минималках как квейк 3.
А зачем именно 50ХХ серию?
Я вон уже второй день спокойно в него играюсь с 3060 на хай настройках графики в 2560х1440 и с 50-60фпс. В обсуждениях в стиме так же отписывались что даже на 2060 вполне нормально игра бегает.
Но не спорю конечно что хватает там нытья в обсуждениях на тему "разрабы сволочи - сделали игру которая не пойдет на наших древних 10ХХ карточках".
Но не спорю конечно что хватает там нытья в обсуждениях на тему "разрабы сволочи - сделали игру которая не пойдет на наших древних 10ХХ карточках".
5% стима однако.
Вообще, смешно выглядят такие комментарии под статьей об оптимизации. Учитывая, что обязательный ray tracing не оптимизирует ничего, кроме расходов разработчика. За что боролись, на то и напоролись, получается.
По такой логике и DirectX/OpenGL лучше не использовать, а то вдруг кто-то захочет запустить игру на карточке без них. Трассировка появилась уже достаточно давно, и, по видимому, никуда исчезать не собирается, так что понятно, что рано или поздно она станет обязательной. Похоже, что это время пришло.
Вообще, смешно выглядят такие комментарии под статьей об оптимизации. Учитывая, что обязательный ray tracing не оптимизирует ничего, кроме расходов разработчика. За что боролись, на то и напоролись, получается.
По сравнению с обычным софтом игры все же на особом положении - разработчики игр стараются все же максимально использовать самые современные технологии для улучшения графики и т.д. в игре и само собой требования к нужным видеокартам стабильно возрастают.
Так что реально достаточно странно выглядят претензии игроков на то что игра 2025 года не пойдет на видеокартах выпущенных лет 8 назад - если мне память не изменяет, то 10ХХ вышли в 2016 году.
При этом игра все еще достаточно щадящая по требованиям. Как я и говорил уже ранее - она вполне нормально идет даже на 20ХХ серии, а та вышла уже около 6 лет назад.
Может вы еще скажете, что автопроизводители не должны делать эти бесконечные никому не нужные ребрендинги каждые пару лет, стимулируя покупателя обновлять авто чаще, чем он действительно в этом нуждается? Что дальше, скажете производителям мобильников не выпускать новую версию линейки каждый год, даже если там буквально нечего придумывать всей матерой команде маркетологов а версию 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 это вероятно небольшое исполнительное устройство, типа термостата
В 64кб умещалась программа управления небольшим заводом
Оптимизация? Нет, просто больше не было
В моём случае это было устройство типа чипа на кредитке - там класс защиты от физического проникновения довольно высокий, поэтому размер кристалла уменьшен до предела (около 1х1 мм) и отсюда такие скромные ресурсы у MCU.
Во Франции есть ST Microelectronics (STM* микроконтроллеры довольно популярны), есть Gemalto (они занимаются банковскими картами с большой долей рынка в мире). Но в целом таких компаний мало конечно, тут вы правы.
Оптимизация... хм... ну так-то оно так - куча программ которые тупят непонятно почему, когда там функционал на уровне 90-х.
А с другой стороны - банальное численное решение уравнений Навье-Стокса которое нужно всем сводится обычно к решению СЛАУ. Ну и... чтобы там оптимизировать... только исходную постановку задачи.
Есть истина в его словах. Уже ПО, выполняющее относительно простые функции весит непомерно много. Как пример balenaEtcher или Kensington Works. Вот должно ПО для записи образов на флэшку или простого конфигурирования трекбола так много весить? Однозначно нет. И, как пример оптимизации, для первого есть аналог USBImager с аналогичным функционалом и на пару, если не тройку, порядков меньше по размеру.
Ну так вот же, с сайта Etcher:
Естественно, если вы умеете только в JS, и очень хотите сделать что-то, работающее локально на компе, вы вряд ли пройдёте мимо Электрона. Но то, что результат получится откровенно отстойным, это будет просто закономерно.
Справедливости ради Visual Studio Code тоже на Электроне, и прекрасно работает. Просто большинство не умеют его готовить.
VS Code - едва ли не единственный известный мне пример нормально работающего софта на Электроне. Поэтому мне кажется, что это не у других разработчиков на Электроне руки кривые, а кривой всё-таки Электрон, а разработчики VS Code сделали невозможное :)
Его оптимизировал весь Microsoft, но тоже получилось не сразу - чего стоит история с потреблением 13% ЦП из-за моргающего курсора.
Да ладно, тот же Obsidian неплохо работает. Так-то, если Электрон - это браузер, то приложение на нём - это такое SPA. А хороших, нетормозящих SPA в Интернете достаточно. :)
«Если звёзды зажигают, значит, это кому-нибудь нужно».
dd весит 76 (семьдесят шесть) килобайт, но, раз тот BalenaEtcher тем не менее существует, значит...
Я считаю, что наоборот, оптимизация в больших масштабах просто противоречит развитию цивилизации. Именно высокое потребление заставляет человечество искать новые решения, открывать новые источники энергии, двигаться вперёд. Это максимально естественный путь для прогресса цивилизации.
Не было бы большого потребления, сидели бы до сих пор в районе экватора, пару бананов на обед закинули и дальше спали. А так - сожрали всё и всех вокруг, стали вынуждены искать пищу, заселили всю планету, освоили земледелие и домашний скот и пошло-поехало...
Какие операционные системы сейчас приближены к модели оптимизации?
На сегодня всю инфраструктуру можно построить на Linux с уже имеющимися, скажем, десктопами. Это конечно не говорит о той оптимизации, о которой имелось ввиду в статье.. но как базис масштабируемости это вполне приемлемо.
написал программист, чей код (дум) запускают на чайниках и калькуляторах. Браво!
У меня есть мощная машина. Она приобретена для выполнения ряда сложных вычислительных задач: работа разнообразных нейросетей локально, работа кодеков, работа компиляторов, и т.п.
То есть у меня в ЛЮБОМ случае мощная машина. Тем, кому мощная машина не нужна - покупают телефоны.
Так вот. У меня мощная машина. Нужен ли мне оптимизированный софт за большие деньги?
Очевидно что нет. То что рядовая программа жрет 20% моего процессора, а не 5% - ничего не меняет. А тот софт, оптимизация которого действительно важна(те самые нейросети, кодеки, компиляторы) хороши, так как над их оптимизацией и работают активно, понимая насколько критична скорость их работы.
Кармак гений, но то что он говорит не соответствует потребительским реалиями.
То есть Вы и дальше будете ездить в булочную на своём БЕЛАЗе.
А если вам понадобится запустить 4-5рядовых программ, то в первом случае это будет 80-100% загрузки, а во втором максимум 25%.
За 25 лет работы с ПК таких потребностей не возникало. Я не могу представить типовые программы, которые бы запущенные в количество 10 штук не дали бы работать современному ПК.
Я не могу представить типовые программы, которые бы запущенные в количество 10 штук не дали бы работать современному ПК
Любая LLM-ка с адекватным размером :)
Это не типовое приложение. Это приложение созданное так, чтобы буквально использовать все доступные ПК ресурсы.
Речь о приложениях, у которых нет задачи использовать все ресурсы, а есть задача выполнять определенную ограниченную работу.
Например, видеоплеер - у него нет задачи максимально быстро проиграть видео. У него задача проиграть видео с той скоростью, с которой это нужно пользователю.
Почтовый клиент не имеет задачи потратить все ресурсы ПК. Его задача периодически получать обновления с новыми письмами.
Тоже самое с IM клиентами и еще кучей софта, который в фоне делает свою работу.
Так вот. У меня мощная машина.
Вопрос в том, хотите ли вы лет через 10 покупать новую мощную машину или продолжать ездить на старой.
Здесь нет вариантов. Мне всё равно придется обновляться. Чтобы нейросети работали нормально, чтобы новые кодеки работали нормально, чтобы компиляция была быстрее.
К примеру, рендер 20 минутного видео сейчас на моем ПК занимает 8 часов времени в FullHD. Я оставляю на ночь и это терпимо. Но, 4К я уже рендерить не могу. Потому что это 24 часа. А это значит мой комп будет не доступен для дневной работы. Я с радостью обновлю ПК чтобы рендерить 4К, когда видеокарты разовьются чтобы рендерить 4К за ночь. И здесь совершенно не важно, насколько рядовые программы жрут ПК. Я всё равно не на них в апгрейде завязан.
Конечно, когда откровенно простенькая утилита жрет несколько гигов и грузит проц на 100% - я не буду её использовать. Но в таких ситуация виноваты кривые руки разрабов, которые "на каждый параметр в json вычисляют полную длину всего json", а не отсутствие жесткой оптимизации.
Согласен, что повляются новые задачи, которые требуют принципиально больше ресурсов. Но, скажем, лично мне для просмотра видео и сейчас хватает 480p, перекодировать его локально а тем более гонять нейросетки не собираюсь. Но при этом банальная загрузка компа до нормального состояния десктора на ноуте примерно десятилетней давности на Ubuntu 22.04 занимает заметно дольше, чем на 11.04 - при том, что тогда я игрался с новомодным на тот момент Unity Desktop, а сейчас в 22.04 оставлен голый WM без DE - даже Lubuntu после перехода на Qt шибко раздулась. Банальная загрузка ленты VK с текстом и картинками у меня и на новом ноуте иногда подтормаживает, хотя несколько лет назад без тормозов грузилась на старом - никакого изменения в функционале я при этом не вижу. И так далее - тормозит именно старая рядовая функциональность, при том что новой мне не надо.
Мне кажется у вас синдром утенка.
У меня есть "ретро" компы дома. Причем разных поколений: 2005, 2008, 2011 года. С старыми же операционками.
Так современные операционки грузятся быстрее. К примеру на одном и том же ПК ХР, Windows 7 и Windows 10 грузятся по разному. И десятка грузится быстрее всех.
UPD: Хотя это субъективное ощущение. Замеры я не проводил. Даже интересно стало проверить.
Винда у меня на старом ноуте только семёрка, как грузилась так и грузится; не знаю, как поведут себя 10/11 на 2Gb оперативки. Но переход от версии к версии Ubuntu (при том, что с 12.04 менял только LTS раз в два года) - событие заметное и дискретное. Правда, сразу в глаза бросился переход с LXDE на LXQt, после которого понял, что оно мне не надо; время загрузки базовой системы менялось плавнее, но есть ощущение, что начали забивать на специфичные для HDD оптимизации.
HDD? почему не SSD?
Потому что HDD дешевле, очевидно. И если он удовлетворяет определенным задачам - зачем переплачивать?
если для коллекции, то конечно лучше оригинальный, если для работы SSD оправдывает стоимость, по опыту в доме нет ни одного на HDD, даже старый laptop, настолько очевидно преимущество, однако для backup есть сервер с HDD, лет десять как было заменено, опыт положительный, но конечно дело личное, надо смотреть по обстоятельствам
Когда покупал железку в 2011ом, SSD были заметно дороже. Сейчас есть другой ноут поновее, этот уже скорее игрушка и тратить на него деньги особого смысла нет - только умершую клавиатурку таки заменил - но всё таки повозиться интересно.
дело хозяйское конечно, но замена на SSD мало время занимает, после этого назад трудно вернуться, настолько разница заметна, когда SSD появились на рынке они дороже стоили, сейчас намного дешевле
С моими кривыми руками замена клавы уже была приключением (хотя и в каком то ролике типа "смотрите как просто" на youtube сломанные защёлки упоминались), до винчестера надо лезть глубже, там есть ещё чего сломать. Так то батарейку CMOS неплохо бы поменять, даже купил, но не рискую разбирать полноута.
Как раз для оживления старых ноутов SSD мастхэв. Они буквально из мертвого мусора превращаются в рабочие железки.
Так вот. У меня мощная машина. Нужен ли мне оптимизированный софт за большие деньги?
А за обычные деньги? Вот смотрите, у меня тоже довольно мощная машина:
Сожрано 43 Гб памяти. Что же такого у меня запущено? А, два инстанса IDE (VS Code и VS 2022), три десятка вкладок браузера и четыре мессенджера. И вам не кажется, что это овердохрена потребления для такого софта? Я не для того покупал мощную машину, чтобы она практически все свои ресурсы тратила на читалку текстов и аську.
Вы неправильно понимаете потребление памяти. Вы ее зачем купили, чтобы любоваться на нее? Память должна работать. Физическая память в винде - это фактически еще один уровень кеша над файлом подкачки. Соответственно, какой-то причины постоянно все из нее выгружать, только чтобы она выглядела незаполненной, вообще нет.
Было бы у вас только 32 Гб памяти, винда бы держала ее заполненной на условные 25гб вместо 43.
Верно. Вспоминается древняя мудрость:
Сколько ОЗУ необходимо Windows?
Всю, что обнаружит.
И это правильно. Вся память должна быть занята. Чего ей пустовать?
Нет данных? Кешируем все что с диска прочитали. Пометить страницы свободными быстро если что.
Не так.
— Сколько памяти занимает Windows?
— Сколько находит — столько и занимает.
Однако справедливости ради, насколько мне известно, кэши на графике не учитываются — они в «пустой» памяти.
Физическая память в винде - это фактически еще один уровень кеша над файлом подкачки.
Кеш не так работает. Винда вообще понятия не имеет, что и сколько ей надо кешировать для приложений. Она выделяет столько памяти, сколько приложения запросили, и самое неприятное - она сама, без подсказок со стороны приложений, не в курсе, можно ли что-то выгружать при нехватке памяти, или нельзя. Да, какими-то вещами она рулит самостоятельно, например, кешированием страниц для исполняемых файлов, тут она в курсе, что используется, а что нет. Но этак 90% из этих сорока гигабайт - это куча, выделенная по запросу приложений. И как раз они должны её освобождать при ненадобности.
Как вы умудряетесь в такое? Вот у меня:
Даже игра запущена
А самое главное, я живу без свопа, если что:
Или вы хромаете?
Хуже, я и хромаю, и фирефоксю, и эджу. Разработка под стек Майкрософт, она такая, бессердечная тварь.
Под вин нет смысла отключать своп, точнее даже отрицательный. Подробности у Руссиновича. В линухе есть.
Смысл есть, кроме пары глючных программ, которые при 0 свопе говорят, что нехватает памяти. Ради них можно держать минимальные 16 мегабайт и тогда они не вякают. Я такое встречал только один раз за последние 12 лет. Жил без свопа на 32ГБ и W7, сейчас на 64ГБ и W10.
Под вин нет смысла отключать своп, точнее даже отрицательный. Подробности у Руссиновича.
Освежил свою память повторным чтением упомянутой статьи от ноября 2008 года под названием "Pushing the Limits of Windows: Virtual Memory". Единственное им упомянутое, что хоть как-то влияет на мой сценарий использования, это невозможность создания дампа памяти в случае ошибки STOP (BSOD). Знаете, я на 7 BSOD на своём ПК видел считанные единицы раз, а на текущем W10 с момента установки (29.11.2022) я ещё ни разу не видел BSOD. Ну и дамп памяти мне всё равно не нужен ибо для меня бесполезен.
BSOD на своём ПК видел считанные единицы раз
Насколько спорим, что этот дамп памяти Вы вообще рассматрирали ровно 0 (ноль) раз?
Нинасколько. Всегда довольствовался только экранной информацией. Правда, в то время это ещё было что-то осмысленное, а теперь это натурально, как говорит Изичка: "ошибка номер х*й". И он полностью прав.
Всегда довольствовался только экранной информацией.
Ну да, раньше хоть диаметр этого номера был ясен!
Ну, например, 0x0000007B расшифровывалось Изей как "ноль, х*й (собственно, поэтому ошибка так и называется), ноль, ноль, ноль, ноль, ноль, ноль, семь бл*дей". Очевидно же, что это "Загрузочный том не доступен"!
А ещё, некоторые ошибки имеют префикс 0xC..., что расшифровывается как "ноль, х*й, cyka, ...". Как правило, это доступ запрещён, если в конце 5, например, или другой какой номерной GPF.
В феврале 2021 года Кармак предложил простой способ борьбы с дефицитом современных видеокарт и игровых консолей нового поколения и засильем спекулянтов. По его мнению, нужно устранить посредников, включая дистрибьюторов и розничных продавцов, между производителями видеокарт и консолей и пользователями. Он предложил для этого сегмента рынка создать прозрачную систему аукционов напрямую от производителей, чтобы более эффективно распространять графические устройства среди пользователей.
кто-то там предложил, а у нас в Беларуси его попробовали. Этот закон "О посредниках" продержался всего пару дней.
Так что незачем перепечатывать всю фигню, которую где-то там запостили в интернетах
Т.е. правильные пацаны не заработали и обозлились?
Нет, просто производители не хотят заниматься дистрибуцией. Это не их профиль деятельности.
Нет, просто производители не хотят заниматься дистрибуцией. Это не их профиль деятельности.
М... Так и не надо? Сгружаем все купленное в условный амзон/алибабу (можно прямо там и продать со своей учетки) - и пускай у маркета голова болит.
Сгружаем все купленное в условный амзон/алибабу
Это не "напрямую от производителей", у вас уже на этапе отгрузки в амазон будут посредники в виде перевозчиков и складов. А если речь о больших объемах - вот вам и оптовые дистрибьюторы появятся, и не от какого-то хитрого заговора, а от банального удобства ведения бизнеса для производителя и продавца.
пускай у маркета голова болит
У него голова болеть будет только о привлечении покупателей конкретно на свою платформу, на ваш товар ему абсолютно плевать.
Это уже не "напрямую от производителей"
Именно продажа - напрямую. Деньги идут от пользователей сразу производителю. А все остальные получают агентские и прочие оплаты за доставку, а не за товар, который сами купили раньше.
Я так понял, в этом и предложение было - чтобы количество шагов "купили - продали кому-то дальше" уменьшилось.
Простите, а как мне магазин вернет деньги за брак тогда? Нет, судиться с ООО Лабеан я не собираюсь. Я купил в крупном магазине и он мне вернуть мои деньги должен.
Простите, а как мне магазин вернет деньги за брак тогда?
Это давний спор. Многошаговая обратная связь вида "Много народу вернуло деньги в магазине" -> "Магазин обиделся и перестал покупать товар этой марки" -> "Оптовик заметил, что на складах товар залеживается и тоже перестал покупать" -> "До производителя дошло что он делает что-то не то" тоже не очень адекватно выглядит. Когда прямо по кошельку производителя бьёт - это как-то доходчивей должно быть.
А так - производитель продал, он же и должен так же (с теми же затратами нервов и времени) возвращать деньги. Т.е., по идее, механизм должен быть встроен в законодательство о маркетплейсах, чтобы можно было прийти в любой, где товары этого производителя лежат, и оформить возврат. Деньги за доставку и прочие расходы - с производителя, ибо он виноват.
Уязвимость - производители-однодневки. Которые успели пропасть между покупкой и желанием возврата.
Уязвимость ответственности на магазине - магазины-однодевки, которые успели пропасть между покупкой и желанием возврата.
То есть деньги не вернут? Я верно понимаю?
И самым выгодным становится плодить однодневки которые хоть тушкой хоть чучелом пролезут на полку и банкротить ее. И пусть взыскивают с бомжа.
А вот настоящему новому-мелкому производителю на полку попасть будет невозможно. К нему будут требования как вон к тем однодневкам. Ни один настоящий производитель их не выполнит.
Вывод: схема не работающая.
И самым выгодным становится плодить однодневки которые хоть тушкой хоть чучелом пролезут на полку и банкротить ее. И пусть взыскивают с бомжа.
Это верно и сейчас - для магазинов. Потому что куда покупатель пойдет, если магазин обанкротился? Но все магазины подряд однодневками не стали.
Магазин это большая оффлайн штука. С большими капитальными вложениями. Он работает напрямую с покупателем.
Однодневки бай дизайн не получаются.
При этом производители это кто угодно. Статьи на Хабре хорошо это подтверждают.
Маркетплейсы должны работать по правилам магазинов. Хотите предоставлять информационные услуги? Не вопрос переадресуйте меня для покупки на сайт продавца и не берите мои деньги. А если деньги взяли - вы магазин и должны отвечать за товар по закону.
Old man yells at cloud.
Невозможно вернуться к старой архитектуре монолитов, это просто банально не безопасно и бессмысленно для бизнеса в рамках production cost. Все забыли наверное как работали банковские приложухи по 4 часа в день, как отваливался интернет стабильно пару раз в сутки, как не работали приложения сайтов отдавая постоянные 500ые ошибки.
Ни бизнесу ни современному человеку это не нужно, им нужна работоспособность 24/7. Именно поэтому пока доступна масштабируемость, бизнес будет вкладываться в развитие, а не в оптимизацию.
В наше время от концепта в голове до рабочей модели может пройти сутки (спасибо нейронкам в том числе), в былые времена продукт пилил десяток разработчиков месяц, что бы потом выйти хотя бы из концепта в рабочий билд.
Оптимизация важна там, где нет масштабируемости. А то, что какой то фрик на своем Pentium lll не сможет запустить какой то продукт, бизнес не волнует и это правильно с точки зрения бизнеса. Ресурсы бизнеса тоже ограничены, можете платить за оптимизацию из своего кармана если так хочется.
А можем не платить, если результаты оптимизации бизнеса нас не устраивает. Свобода.
Ну компьютеры - вещь относительно дешёвая, вычислительные кластеры, скажем от Оракла, уже подороже, и бизнес начинает чесаться.
Но, например, пользуйтесь результатами оптимизации бизнеса в автопроме, наслаждайтесь =)
Если бизнес хочет, то он может обсыпаться топовым железом со своей стороны, но я не думаю, что типовой пользователь хочет постоянно масштабироваться со своей стороны для простого выполнения своих типовых здач.
А что, ИИ не осилит в чистый asm под конкретную платформу? Интересно посмотреть, что может получиться с точки зрения объема кода и скорости исполнения. Скорее в играх, чем в бизнес критикал конечно
ИИ не нужно в чистый asm. Зачем? Современные компиляторы прекрасно справляются с задачами оптимизации. Поэтому LLM верхнего уровняю пишут код на вполне человекочитаемых языках. А уже компиляторы превращают это в оптимизированный код.
И опять же, проблемы оптимизации давно не на уровне языков. Они на уровне архитектурных решений. От того что вы сэкономите такт на вызове функции или на итерации цикла - ничего глобально не изменится. От того что вы сделаете фигню в виде вычисления длины json при парсинге каждого параметра - эффект будет значительный.
Чем менее употребим язык, тем хуже на нем пишут сетки. Ну и задачу "перепиши этот код на вот этом языке, чтобы он проходил вот эти тесты" сетки пока решать не умеют. Так бы можно было бы держать две ветки: dev - который пишут люди на условном жс, и stable - на ассемблере с заточкой под конкретную ифраструктуру, который из dev генерирует сетка.
Это говорит человек, почти каждая игра которого начиная с Doom была причиной массового апгрейда ПК по всему миру и чьи игры регулярно становились бенчмарками производительности?) Да, игры как-то шли на не топовом железе, и я лично на 486 запускал Quake в режиме "спичечный коробок" чтоб выжать что-то в районе 25 кадров в среднем, и Doom 3 я запускал в 320x240 (не шутка), но блин, как забавно то звучит от него такие заявления)
Вопрос в том, на что тратятся транзисторы и циклы нового железа - на более продвинутую графику/физику и прочие расчёты или бесцельное перекидывание jsonчиков.
Кармак в 1992 году написал 3D-движок с текстурами, который вытягивал играбельные fps на обычном персональном компьютере. Это величайший известный мне специалист по микрооптимизации.
Очень рекомендую его 5-часовое интервью с Лексом Фридманом.
Timestamp про текстуры: https://www.youtube.com/watch?v=I845O57ZSy4&t=8291s
Справедливости ради, это времена когда только хороший VGA-адаптер за один "кинематографический" кадр успевал обновить все пиксели в этом 320x240. А работа Quake была возможна благодаря таким оптимизациям.
У нас на проде самому нагруженному сервису выделено 4Gb RAM и 4 ядра. Это фид стаканов и котировок для трейдинга. Рассылает 40k эвентов в секунду по шине плюс эти же 40к эвентов пишет в файловое хранилище и в кафку. Написан на котлине. По железу это уровень ноутбуков из нулевых. Причем, у нас есть идея, как нагрузку на CPU снизить еще где-то на треть. Если порвать дупшу, то можно и на голанг или раст переписать - футпринт по памяти наверное снизится. Но таких компетенций нет в команде.
Так что не все так печально с оптимизацией. Хотя, возможно, пинок Кармака направлен только в сторону игропрома.
На игропром странно пенять. Сейчас все целятся на мобилки и оптимизациями занимаются по максимуму. А triple-A игры всё равно будут требовательными, как их не оптимизируй.
Сейчас все целятся на мобилки и оптимизациями занимаются по максимуму.
Куча мобильных гача-игр где оптимизация весьма сомнительная. В одной из самых кассовых игр подгрузки между разными меню (в игре без 3d элементов!) до 5-10 секунд занимают. А все почему? Потому что делать по-другому в unity слишком трудозатратно для разработчиков, раскидаем все на кучу сцен и будем постоянно между ними прогружаться.
Это автор вот той самой Rage, у которой на любой видеокарте текстуры подгружались на глазах у изумленного пользователя? Это вот он нам про оптимизацию рассказывает?
Мы живём при капитализме. Это значит, что всем правит прибыль.
Решение закидать проблему производительности железом возникает не на пустом месте. Это работает гораздо быстрее оптимизации ПО, а, значит, продукт выходит на рынок раньше, и начинает приносить прибыль.
Если вместо выпуска продукта на рынок заниматься оптимизацией, это будет означать, что всё это время оптимизации будет в минус прибыли, а конкуренты выкатят свой продукт раньше.
Мне очень нравится, когда артисты, спортсмены, мисс Вселенная и программисты дают рецепты о том, как нам исправить экономику, но это, как минимум, наивно.
Джон Кармак: мы все могли бы работать на старом компьютерном оборудовании, если бы оптимизация ПО была приоритетом