Несколько недель назад мы обсуждали Java-компонент, запускающий кластер Spark. Его основная задача — координация. Он поднимает всю необходимую инфраструктуру, прокидывает конфигурацию, дожидается нужных сигналов и отходит на второй план.
Моё изначальное предложение прозвучало просто: «Ему вполне должно хватить одного ядра и 2 ГБ RAM. Это же всего лишь лаунчер». Хотя даже 2 ГБ казалось будто бы мало, ведь речь о продакшене, а не о каких-то экспериментах на личном ноутбуке. Но как раз в таком мышлении и кроется проблема. В процессе развития сферы вычислений мы постепенно перестали всерьёз воспринимать небольшие числа при обсуждении ресурсов, так как дорожим устойчивостью системы. Но в продакшене нужно, наоборот, распоряжаться ресурсами более аккуратно.
Думаю, мы все знаем, как это бывает. Если вы уже варитесь в этом бизнесе какое-то время, то сами так поступали. Пайплайн даёт сбой — увеличиваем память. Сервис начинает тормозить — добавляем процессорных ядер. Роллаут прошёл с натягом — и вот дежурный разработчик уже закладывает огромный буфер, потому что никто не хочет снова подрываться ночью по тревоге. Большие числа работают, система выглядит надёжной, и мы движемся дальше.
В итоге через полгода исходный контекст напрочь забывается, и такая конфигурация становится для сервиса объективным стандартом. Уже никто не рассматривает её как временный фикс. Теперь — это жёсткое требование. Временная заплатка затвердевает и превращается в непреложный факт, и никто не хочет ставить это под сомнение — ведь система работает.
Получается эдакий парадокс. JVM десятилетиями оптимизировалась, сборщики мусора стали намного эффективнее, процессоры — быстрее, а облачные ресурсы выделяются по щелчку мыши. В теории мы должны буквально купаться в плодах этих достижений. Но по факту мы продолжаем их растрачивать, подтверждая закон Никлауса Вирта, сформулированный им ещё в 1995:
«Программное обеспечение замедляется быстрее, чем ускоряется железо».
К чему нас привёл прогресс
Но плоды достижений никуда не исчезли. Просто мы растратили их на раздутые рантаймы, бесконечные графы зависимостей, тяжеловесные контейнеры, тонны телеметрии, расширенные запасы прочности и стандартные шаблоны платформ, из-за которых все сервисы выглядят одинаково. Когда появление очередной высокоуровневой абстракции повышает эффективность программирования, мы не начинаем писать меньше кода или создавать более простые системы. Мы тратим эту эффективность на повышение сложности, дополнительные интеграции и увеличение числа подвижных компонентов.
Когда инженер задирает лимит памяти контейнера «про запас», эргономика JVM воспринимает этот запас как предложение ни в чём себе не отказывать. Как результат, дефолтный размер кучи увеличивается до установленной доли от выделенных ресурсов. Сборщик мусора начинает лениться, так как теперь есть где разгуляться. А среда выполнения с комфортом обживает тот простор, который ей предоставили. Программное обеспечение начинает есть больше не от того, что теперь нужно больше работать. Оно просто расширяется, поглощая тот ресурс, который ему выделили.
Да, отчасти это утяжеление оправдано. Я не хочу угодить в ловушку технической ностальгии. Но нам нужно провести черту между неизбежной сложностью и излишними тратами. Современные программы выполняются во враждебной глобальной среде. Часть их веса вполне оправдана — это и безопасность, и доступность, и распределённые системы, и соответствие стандартам, и наблюдаемость, и глобальное масштабирование. Сегодняшние системы выполняют намного больше всевозможной работы, чем старые. Наша же ошибка в том, что мы используем этот аргумент для защиты любой неудачной базовой конфигурации, возникшей в процессе работы.
Если проанализировать явные излишки, то в глаза бросаются раздутые деревья зависимостей, в которых значительное число подключенных библиотек запускаются в рантайме редко или не запускаются вовсе. У каждого слоя современного программного стека есть свой аппетит. Логирование, трассировка, SDK платформы, и базовый образ контейнера — все хотят свою долю. Причём по отдельности ни один из них вроде и не требует чего-то запредельного, но все вместе они уже способны превратить небольшую утилиту в неповоротливого монстра. Раздутость ПО не возникает на ровном месте, она становится результатом длинной серии вполне разумных ситуативных решений.
Раньше машины умели сказать «Нет»
В прошлом ПО работало быстро не от того, что разработчики отличались высокой сознательностью. Просто машина могла сказать «Нет». В 2000-х годах было нормальным запускать веб-сервис на двухъядерной или даже одноядерной машине с несколькими гигабайтами памяти. Сервер был скромным, поэтому код приходилось затачивать под эти рамки. Нужно было расставлять приоритеты, подстраивать систему и точно понимать, что конкретно делает этот сервис. Ограничения заставляли людей действовать вдумчиво и экономично.
Современная же инфраструктура куда менее строга. Мы с лёгкостью добавляем буферы, повторные попытки и стандартные слои платформы — просто на всякий случай. С одной стороны, эта аппаратная снисходительность позволяет нам создавать более масштабные системы, а с другой, постепенно превращает временные перерасходы в постоянные и уже как будто нормальные. Использование инстанса более высокого уровня может нивелировать запутанную архитектуру. Увеличение кучи — скрыть утечку памяти. А применение стандартного шаблона платформы — скрыть тот факт, что крохотный координатор наследует аппетит более масштабного сервиса — потому что выделение 2 ГБ здесь кажется какой-то шуткой.
Но есть и обратная сторона медали. Сервис, использующий лишь жалкие 10% от выделенных ему 64 ГБ, на графике мониторинга отражается красивым, умиротворяющим зелёным цветом. Для команды эксплуатации этот сигнал означает, что с ним всё в порядке, хотя на деле он маскирует возможные проблемы оптимизации под триумф операционной безопасности. Мы разработали исчерпывающие механизмы тревоги на случаи перегрузки систем, но редко создаём такие механизмы для проверки структурной пустоты.
Образно говоря, дистанция между разработчиком и машиной радикально сократилась. Раньше для увеличения производительности нужно было заказывать железо, устанавливать дополнительные модули RAM, ждать поставки сервера или выбивать бюджет у руководства. В таких условиях нужно было думать дважды. Возникали лишние заминки, которые шли на пользу, заставляя тебя поумерить аппетит и действовать более эффективно. Сегодня же все эти вопросы решаются простым изменением конфигурации.
Мы стали расточительными не потому, что современным разработчикам всё до лампочки. Просто сегодня возникновение лишних трат редко сопровождается острой необходимостью их аргументировать.
Теперь отдувается железо
Заткнуть проблему железом бывает несложно, и зачастую это действительно является экономически оправданным решением. Человеческий труд намного дороже машинного. Если трата нескольких долларов на вычисления способна сэкономить дорогостоящее время разработчика, то ручная оптимизация кода станет неудачным вложением средств.
Но проблема в том, что аппаратное масштабирование становится как будто единственным решением. Когда так происходит, любое узкое место в системе превращается исключительно в проблему выделения ресурсов. Если мы видим, что нода перегружается, то для стабилизации системы переходим на более крупную. Но здесь кроется подвох, потому что стабильность может иметь под собой два совершенно разных фундамента. Иногда стабильная система имеет действительно стройную форму. В других же случаях мы просто заливаем проблему деньгами, чтобы она не вскрылась ночным сбоем.
И второй вид можно легко по ошибке принять за успех, так как прод работает исправно. В итоге возникает чувство «победы», и мы забываем, какой ценой эта победа нам досталась.
Избыточность живёт за чужой счёт
Перерасход ресурсов сохраняется, потому что сопутствующие издержки всегда перекладываются на чужие плечи. Тот, кто вносит зависимость, ускоряет разработку сегодня, а вся сопутствующая боль по обслуживанию переходит будущему мейнтейнеру. Команда платформы добавляет какой-то стандартный сайдкар лишь раз, но все сервисы в итоге расплачиваются за это задержкой бесконечно. Продуктовая команда прикручивает трекер для монетизации внимания пользователей, за что сами пользователи расплачиваются зарядом батареи и когнитивной нагрузкой.
В итоге раздувание продолжается, даже если его никто не одобряет, потому что циклы обратной связи нарушены. Когда сервис падает, фиксируется инцидент, проводится разбор полётов и возникает ощущение неотложности. Если же сильно тупит корпоративный инструмент, то это не порождает ничего, кроме ежедневной волокиты. Любой, кто пользовался кривым корпоративным софтом, знает, что эта медлительность никогда не переходит в разряд инцидентов. Она просто превращается в фоновые издержки при выполнении работы.
Решение: бюджетирование ресурсов
Ответом на эту проблему станет введение бюджетов на ресурсы — простых, занудных и жёстко фиксированных бюджетов. Тогда и лаунчеру будет выделен свой бюджет, и сервис получит стартовый бюджет, и контейнер получит бюджет на размер. Когда же выданный лимит будет превышен, кому-то придётся объяснить, что конкретно изменилось, и чем реально оправдывается этот лишний расход.
Это не означает, что придётся вручную оптимизировать потребление каждого байта. Иногда дополнительное аппаратное обеспечение обходится дешевле, чем координирование человеческого труда. Некоторые абстракции обеспечивают достаточно безопасности, чтобы оправдать свои расходы. Наша цель — не бедность, а осознанность. Давайте делать эти компромиссы прозрачными, прежде чем раздутые догадки закрепятся в виде стандарта.
Если простому лаунчеру Spark действительно нужно тридцать гигабайт, хорошо. Но покажите мне «чеки». Что именно загружается при запуске? Что постоянно висит в памяти? Какая часть этой памяти действительно обеспечивает отказоустойчивость системы, а какая лишь оплачивает проценты на старые, давно забытые решения?
Если никто не сможет ответить на эти вопросы, то такое выделение памяти — это не инженерия, а суеверие. Поэтому в следующий раз, когда какой-то отдельный компонент потребует огромных ресурсов, не нужно оправдывать его, оглядываясь на аппетиты соседних сервисов. Оцените структуру выполняемой им работы. Задайтесь вопросом, что конкретно делает тот или иной механизм, и что нам нужно изменить, чтобы перестать панически бояться скромных цифр.
Комментарии (93)
oldzoomer_ru
28.06.2026 09:29В 2000-х годах было нормальным запускать веб-сервис на двухъядерной или даже одноядерной машине с несколькими гигабайтами памяти.
Скажу со своей колокольни - ваадиновой.
Так вот, Vaadin всегда был про server-side states. Поэтому она и прославилась тем, что требует сервер с большим объёмом ОЗУ.
Поэтому пока на тимлифе делали относительно нежручие UI, ваадинщики юзали server-side states (которые хранятся в ОЗУ сервера) по полной.
GidraVydra
28.06.2026 09:29Раньше ПО работало шустро
Как же быстро в человеческом мозгу объективная картина подменяется на воспоминания о зелёной траве и самом вкусном пломбире...
oldzoomer_ru
28.06.2026 09:29Вспоминаем тот же IE. Или iTunes.
Aggle
28.06.2026 09:29Ещё можно вспомнить:
"А кто будет жрать память, того будем бить по наглой рыжей морде". (ц)
vorphalack
28.06.2026 09:29в вычислительном плане оно может и с той же относительной скоростью работало, а вот отзывчивость UI точно была выше, потому что никто тебе контекстные меню на react native не делал с десятью анимациями для олигофренов и еще 5 для даунов.
AcckiyGerman
28.06.2026 09:29Отлично помню, как отключал все эти анимации в win 98 и win XP чтобы не лагали.
vorphalack
28.06.2026 09:29я их местами тоже отключал, да,но - там у меня был выбор (а если чуть накинуть железа - то и даже пофиг было),потому что условно у всех был win32/mfc и поверх скины к нему, а щас там минимум WPF или "тулкит дня + JS/HTML" или даже целый электрон, всё с визуальными эффектами, тупит, и вдобавок еще глючит на недефолтных dpi, как бы они не проповедовали обратное.
vlivyur
28.06.2026 09:29И тогда, наконец-то, система работала адекватно. Т.е. её можно было штатными средствами заставить работать. А больше такой возможности нет. Сейчас у меня под Win11 task manager умудряется иногда под 20% CPU сжирать
Wesha
28.06.2026 09:29все эти анимации в win 98 и win XP
Тогда‑то и появился оборот «свистелки и перделки».
(Дедушка старый. Дедушка помнит.)
Darkness_Paladin
28.06.2026 09:29Ну это у вас наверное железо было совсем плохое. В ХРюшке я отключал только "новый стиль окон" и исключительно ради экономии места на экране, анимации отключал только в 98й на 486м.
GidraVydra
28.06.2026 09:29Мне, как пользователю нескольких ретрокомпьютеров, очень интересно бывает читать подобные прохладные истории...
asdadn
28.06.2026 09:29Ретрокомпьютер это commdore 64 или компьютер из нулевых на котором xp стоит?
GidraVydra
28.06.2026 09:29Это компьютеры из начала и середины 90х.
asdadn
28.06.2026 09:29Так это невероятно слабые по нынешнем меркам компьютеры. А сколько сейчас приложений, реализующих функциональность не сильно превосходящую функциональность софта тех времён и при этом работающих нерасторопно? Речь как раз о том, что сейчас-то эту нерасторопность оправдать намного сложнее.
GidraVydra
28.06.2026 09:29функциональность не сильно превосходящую функциональность софта тех времён
Угу. Например, Doom 1993 года и Doom 2016 года. Функционально ровно одно и то же - бегаешь, стреляешь.
tsypanov
28.06.2026 09:29Статья немного о другом, а именно об изменившемся подходе к решению проблем производительности. От улучшения алгоритмов и структур данных разработчики пришли к закармливанию ПО памятью и процессорами.
Darkness_Paladin
28.06.2026 09:29Ничего нового, на самом деле. Проблемы производительности ВСЕГДА, с самых древних времён, решают ровно тем путём, который дешевле именно в данный момент времени. Дешевле улучшить технологию -- её улучшают. Дешевле тупо нарастить поточность -- наращивают поточность.
По статистике, эти два пути обычно поочерёдно сменяют друг друга. На каком-то уровне наращивание поточности на старой технологии начинает буксовать, и оказывается выгодно апгрейдить технологию, заменив, к примеру, тысячу землекопов с тачками одним экскаватором. Где один, там и второй, и сотый -- а потом сотню маленьких экскаваторов оказывается выгодно заменить одним большим.
Fenzales
28.06.2026 09:29в вычислительном плане оно может и с той же относительной скоростью работало, а вот отзывчивость UI точно была выше
Особенно когда было непонятно: приложение зависло или просто что-то считает :)
vorphalack
28.06.2026 09:29как будто что-то с тех пор изменилось... правда теперь из-за этих новомодных тулкитов сверху третья напасть добавилась - "пропустило хоткей"
AlekseyPraskovin
28.06.2026 09:29А сейчас-то понятно, ага. Особенно ваши любимые бесконечные спиннеры вместо нормального прогресс бара. И ошибки с описанием типа "Извините, что-то пошло не так. Идите нахуй" на фронте.
GidraVydra
28.06.2026 09:29вместо нормального прогресс бара
Того самого "нормального прогресс-бара", который обычно 10 минут стоял как вкопанный, а потом за 3 секунды прыгал на 80%?
Darkness_Paladin
28.06.2026 09:29Особенно ваши любимые бесконечные спиннеры вместо нормального прогресс бара.
Того самого "нормального прогресс-бара", включение которого в Norton Commander на треть замедляло удаление больших директорий, да? Того, который в современных виндах заставляет систему тратить кучу времени зря перед попыткой переместить или удалить папку с кучей мелочи?
С "нормальным п-б" есть одна проблемка: чтоб он работал, ему надо указать MaxValue, процесс приближения к которому он собственно и показывает. Если вы хотите прогрессбар, который покажет прогресс очистки корзины -- значит, вам перед началом очистки нужно рекурсивно пробежаться по всем лежащим в корзине папкам, посчитать файлы в них и присвоить параметру MaxValue полученное значение, чтоб присвоение значения счётчика уже удалённых файлов параметру Value отображало реальный прогресс выполнения задачи.
И вторая проблема. Нелинейность. Часто задача, символизируемая прогрессбаром, состоит из нескольких подзадач, скорость которых зависит от конкретного железа. Может, я на своём компе и подберу коэффициенты, чтоб прогрессбар полз с постоянной скоростью -- но абсолютно не факт, что на вашем компе скорость тоже будет постоянной.
И третья проблема. Иногда продолжительность выполнения задачи вообще нельзя предсказать заранее. Самый простой, наверное, пример: книга эксель, в ней два листа. Надо пробежаться по столбцу "артикул" в первом листе, для каждого артикула найти на втором листе все строки с его упоминанием, и скопировать их в новую книгу. Сколько всего строк будет скопировано -- мы узнаем, только когда работа будет завершена. Можно привязать прогрессбар к счётчику цикла, проходящего по первому листу, но тогда он будет крайне неравномерен, т.к. для одних артикулов мы будем почти моментально получать результат "такого нет во втором листе", а для других, возможно, для увеличения Value прогрессбара на единичку придётся скопировать несколько тысяч строчек.
vlivyur
28.06.2026 09:29Надо пробежаться по столбцу "артикул"
Перемножить два числа: количество артикулов на количество строк на втором листе
Удаление из корзины тоже не самая большая проблема-Far умеет предварительно сканировать весь каталог и показывать прогресс при удалении.Да,чуть дольше,но работает
В конце-концов можно рекурсивно дробить прогресс-бар (удаляем каталог,а внутри 5других каталогов и сотня файлов-шаг на этом этапе будет 1/6,читаем первый вложенный каталог-там ещё 10каталогов и само содержимое этого каталога-теперь 1/6 делим ещё на 11-и это становится новым шагом для этой 1/6 доли) или увеличивать MaxValue по мере чтения новых каталогов-да,это не очень,но всё ещё показывает какой-никакой прогресс. Это не даёт возможности оценить как долго это ещё будет продолжаться,но это делает "осязаемым" процесс удаления.А не так,что основной поток уже давным-давно завис,а gifка в отдельном потоке просто крутится
randomsimplenumber
28.06.2026 09:29Кроме наименования переменных, есть еще одна фундаментальная проблема в ИТ - реализация прогрессбара.
pavel_str
28.06.2026 09:29Не совсем верно. Возьмите старый ноутбук с ХР и пол гига памяти, поставьте на него Word 2007. И сравните время открытия одного и того же документа на этом ноутбуке и современном компьютере... Мне как то принесли старый ноут и разница была очень заметная и не в пользу моего рабочего на Win10 значительно более современного компьютера.
Hlad
28.06.2026 09:29Ну, тут есть нюанс. Раньше считалось, что пользователь понимает, что делает, соответственно, сказали запустить - значит запустить. А сейчас считается, что пользователь идиот, который не ест говно только потому, что ему цвет не нравится. Поэтому когда вы жмёте "запустить" - происходит куча телодвижений, чтобы убедиться, что это приложение безопасно. Вплоть до запроса через интернет на сервера Микрософта. Попробуйте на роутере зажать канал до 32 килобит в секунду, и запустить что-нибудь.
GidraVydra
28.06.2026 09:29На 512 мб ХР SP3 сама по себе не особо шустро работает, а уж 2007 ворд на таких мозгах будет открываться вечность. У меня на работе штук 5 компов с хрюшей, но минимум с 1 гб. И то там даже 2003 ворд не особо шустро работает, документ на 200 страниц с картинками секунд 15 открывает. Мой нынешний ноут, который я 5 лет назад за 400 евро брал, этот же файл в 19 ворде откроет секунды за 3-4.
И при всём при этом по функционалу 2019 ворд гораздо богаче 2003 или 2007. Из того, чем я регулярно пользуюсь: рилтайм-синхронизация с облаком, распознавание рукописного ввода, распознавание речи, плагины EndNote и Mendeley.
speshuric
28.06.2026 09:29А тут несколько разнонаправленных трендов.
С одной стороны, многие библиотеки бесконечно улучшают: тут SIMD воткнут, там алгоритм от квадратичного в граничных случаях избавится, где-то от расчётов ненужных избавятся, где-то от false sharing. Если посмотреть на производительность конкретной фичи с точки зрения кода, то обычно она становится лучше (это если она на стеке-долгожителе, а не была переписана с C++ на python, конечно).
С другой стороны, как правильно указано в статье - навешиваются какие-то безумные с точки зрения конечной функции расходы. То предсказание переходов безопасности мешает, то в контейнер (а то и виртуалку) надо запихнуть, перейдя с внутрипроцессного вызова на TCP+TLS RPC. Ну и по мелочи - указатели стали в 2 раза толще, int64 стал чаще типом по умолчанию и т.п. Причём на самом деле 80% этого можно найти и устранить но обычно "оно не стоит того". И это "не стоит того" для одного конкретного фактора приводит к непрерывному росту ПО. Везде. Не все его замечают, потому что он медленный, но это как расширение вселенной - становится главным фактором на больших масштабах. Причем это почти везде. Я помню нытьё, что dotnet увеличивал размер дистрибутива на 30 МБ. Я вижу, что iso-образ archlinux (который вообще-то неизменно умеет минимум: только загрузиться, немного починить что сломалось и загрузить пакеты из интернета) растёт раза в 2 за каждые 5-7 лет. Блин, archlinux - самый минималистичный iso из всех - стал 1,5 ГБ!
Еще отдельный фактор - изменение железа, например, уход с тех пор с HDD. Если я запущу условную WinNT4 в виртуалке, то я ж расплачусь от того как она быстро будет работать. Ну да. Только тогда у меня памяти было 64МБ, а сейчас 128ГБ, тогда latency диска была 10 мс, а сейчас 20 мкс, тогда диск мог отдать 50 МБ/с, а сейчас 3 ГБ/с. Пожалуй, только latency DRAM плюс-минус там же осталась (сначала упав, а теперь уже лет 20 растёт). Так вот: сейчас ВМ с WinXP/NT4/2000/2003 работает неприлично быстро и экономично по сравнению с нынешними ОС и с самой собой 25-летней давности. Причём основные улучшения в отзывчивости от скорости SSD.
Отдельно замечу, что много нетехнических свойств у систем, которые влияют на их использование. Ну вот тот же GDPR - теперь на каждом милипусеньком сайте торчат всплывашки на первом выхове.
И там еще много подобных факторов. И в итоге у нас одновременно есть и эффект "раньше было лучше", и "стало в 100 раз быстрее".
PS: в 2000 году на NT4 я мог запустить на 1 ядре и 64 МБ памяти SQL Server, его Enterprise Manager, Query Analyzer и еще и HoMM3 (но, если честно, то обычно перед запуском HoMM я всё остальное гасил). А сейчас у меня пустой блокнот ест сопоставимо (notepad.exe - 30 МБ, kwrite - 100 МБ). И с другой стороны, я могу (теперь скорее сын может) играть с разрешением 100 fps на экране 3840x1920 с честной 3d-графикой, трассировкой лучей и правдоподобной физикой, а у меня тогда еле хватало на HL в 640x480 (в 24 раза меньше пикселей).
DerTosser
28.06.2026 09:29Блин, archlinux - самый минималистичный iso из всех - стал 1,5 ГБ!
Самый минималистичный из ныне живущих это TinyCoreLinux, который в максимальной своей комплектации CorePlus занимает 248 MB (GUI и дрова для всякого). Ваш Арч, увы, слишком прожорлив для категории минималистичных. Он скорее самый маленький из дистрибутивов общего назначения. Хотя если взять тот же Debian 13 net-install и накатить на него сверху GUI, он тоже будет не слишком большим, да и PCLOS-mini с TDE всего лишь 2,3 ГБ, но там ещё приложений по минимуму воткнуто. Увы, арч не маленький.
P.S. у меня notepad++.exe с 7-ю открытыми вкладками занимает 8 804 КБ, а там и подсветка синтаксиса и автодополнение и плагины... зачем пользовать обычный notepad, когда есть такая прелесть?
speshuric
28.06.2026 09:29Про arch, что он не самый маленький - принимается. Я скорее имел в виду, что его установочный образ заметно меньше обычных GUI live инсталляторов. В любом случае, я его упомянул, потому что мне проще было посмотреть историю размеров, при том что функционально изменения за это время минимальны. У той же ubuntu тенденция похожая. И у debian, и у остальных (общего назначения) то же самое.
Причём я когда-то смотрел, почему там такой рост. Что меня тогда зацепило, что в образе-инсталляторе arch лежали библиотеки рантайма go для компиляции через gcc (это около 50 МБ одна soшка, если мне память не изменяет). При том, что рантайм go в этом образе вообще был не нужен. Мне стало лень писать мейнейнеру предложение о разделении (чтобы этот рантайм тянулся по зависимостям) - я в тот момент просто собирал образ для экспериментов.
PS: notepad посмотрел просто для примера, зайдя по RDP. Да, notepad++ меньше, конечно, при невообразимо более широких возможностях. А notepad, как и kwrite, я использую для одноразовых заметок.
Tuesok
28.06.2026 09:29Смотря какое ПО и на каком железе. Понятно, что в 3D Studio на 486sx я запускал рендеринг сложной сцены и шел не то, что чай попить - а спать до утра. Сейчас этим уже давно не занимаюсь, но подозреваю, что на современном железе задачи того же уровня решаются быстрее.
А вот условный MS Word 6.0 на этой же железке бегал куда быстрее, чем Office 2024 на современном ПК сопоставимого уровня.
Секунда ностальгии, зеленой травы и старых интерфейсов
Причем по используемому функционалу Word 6.0 закроет потребности большинства пользователей (софт 30+ летней давности).
GidraVydra
28.06.2026 09:29по используемому функционалу Word 6.0 закроет потребности большинства пользователей
Я бы на вашем месте не стал столь категорично говорить от лица большинства. Ваш ворд 6.0 может сохранять в pdf, например? Или как у него обстоят дела с работой с изображениями, можно прямо в ворде обрезать картинку, подправить яркость и цветовой баланс? Это функции, которые могут понадобиться любому школьнику или домохозяйке.
условный MS Word 6.0 на этой же железке бегал куда быстрее, чем Office 2024 на современном ПК сопоставимого уровня
Очень сомневаюсь. 486sx вышел на 2 года раньше 6 ворда, в 91 году, и, как говорит Вики, стоил этот проц на тот момент 258$. Значит, сопоставимый уровень для word 2024 - это проц 2022 года стоимостью, с учетом инфляции доллара, около 600 долларов. Это нихрена себе какой камень, за эти деньги в 22 году можно было купить 7900X, на минуточку, и на сборке с адекватным стоимости камня объемом ОЗУ word 2024 будет летать как птичка. Да даже на моем стационарнике, где стоит примерно втрое дешевший 7600Х, ворд работает без каких-либо задержек.
Darkness_Paladin
28.06.2026 09:29Ваш ворд 6.0 может сохранять в pdf, например?
ПДФ-принтер. Система считает его принтером, а он сохраняет посланное на печать в виде пдф-файлов. Я юзал его с 97м вордом, но и с шестым, вероятно, будет работать.
Или как у него обстоят дела с работой с изображениями, можно прямо в ворде обрезать картинку, подправить яркость и цветовой баланс?
Насколько я помню, да.
Dreams_and_magic
28.06.2026 09:29Раньше ПО работало шустро в одном случае: когда старое ПО ставили на новое железо.
JBFW
28.06.2026 09:29Да, но сейчас-то железо новое?
Прям очень-очень новое, не какой-нибудь Пентиум-133 с 4 МЕГАбайтами памяти - но тогда он худо-бедно крутил новостной сайт на 100500 страниц. Как бы шустро работало это на современном многоядерном сервере с 64 гигами ...Dreams_and_magic
28.06.2026 09:29Многоядерный сервер в сравнении на 1 поток запросто может быть гораздо слабее многоядерного процессора для ПК:)
randomsimplenumber
28.06.2026 09:29новостной сайт на 100500 страниц
1 страница чистого html по факту.
diakin
28.06.2026 09:29
0xC0CAC01A
28.06.2026 09:29Я вот надеялся, что ИИ что-то сделает с этой самой всратостью. Но, похоже, будет только хуже.
Gradiens
28.06.2026 09:29Я из тех, кому 640кб под MSDOS казались роскошью.
И сейчас я побуду адвокатом дьявола.
Вы правы, часто проблему заливают даже не физическтм железом, а деньгами. А что в этом плохого? Ну то есть если этот путь эффективный, может так и надо?
Это же не ваши бабки.
Почему бы не дать приложению в 5 раз больше памяти, и не париться об инцидентах с эпизодическим out of memory, когда кто-то, скажем, сгенерит гигантский отчет?
Почему бы не дать эту память, чтобы сборщик мусора мог оптимально работать, а не устраивать постоянные перетряхивание рабочего набора, от которых у клиентов все лагает?
Если вы не пишете реальный high load, то может, ну его нафиг, преждевременную оптимизацию?
Dreams_and_magic
28.06.2026 09:29А потом какие-то умники из какого-то Гугла придумали какие-то нейросети, и теперь ваша память стоит в 3 раза дороже:)
sim31r
28.06.2026 09:29Так и есть. Допустим проект без оптимизации, протестировали, работает и далее оптимизировать его на 99% не будут. Если жалоб у пользователей нет, то задачу такую ни кто отдельно не поставит.
vorphalack
28.06.2026 09:29это хорошо работает для серверсайда, но есть и клиентская сторона. что такого за 10 лет поменялось в андроиде, что у нас теперь 8 ядер и 12+ гигабайт оперативки в телефонах нужны просто чтоб переключение между аппками не тормозило? может всё же иногда стоит останавливаться и давать не в 5 раз больше приложению, а леща продуктовой команде?
alliumnsk
28.06.2026 09:29Продуктовой? Я плохо разбираюсь в андроиде, но кмк там затруднено написание маложрущих приложений, да и зачем заморачиваться, если сама система много жрет?
Gradiens
28.06.2026 09:29На сервере хотя бы надо задумываться, что железо стоит денег. А ваш телефон для продуктовой команды - бесплатный.
Я никого не хочу оправдывать, я сам как пользователь продолжаю есть кактус (то есть регулярно заношу денег чтобы купить новый телефон)
Но посудите с точки зрения бизнеса, что важнее? Быстрее и дешевле выкатить тяжелую аппку, или заморочится оптимизацией? Бизнес - он ради денег, а не чтобы мир стал лучше.
Если аппка будет "как у всех", то ответ очевиден. Если сильно больше - то да, пользователи уйдут. Если меньше - то пользователи внутренне похвалят, но денег вряд ли принесет.
Был бы жесткий отбор по размеру - эволюция аппок свернула бы в сторону оптимизаций. Но увы. Отбора нет. Пользователи "хавают"
Darkness_Paladin
28.06.2026 09:29А ваш телефон для продуктовой команды - бесплатный.
Не совсем так. Если мой телефон не тянет их продукт, вероятнее, я этим продуктом не стану пользоваться, а не побегу менять телефон. Убыток получится. Поэтому "продуктовая команда" вынуждена ориентироваться на хорошую работу своего продукта на наиболее массовом сегменте клиентского оборудования.
d3d14
28.06.2026 09:29Да хотя бы отзывчивый интерфейс приложений пусть делают. А не это вот рисование меню через <div> на javascript во встроенном браузере. Или в 11 винде - виндовые (!) меню - через какой то чертов XML island, открываются заметно дольше настоящих. Чем настоящие (CreateMenu/TrackPopupMenu) то их не устроили? Вот что в них было плохого - они все поддерживали.
LeVoN_CCCP
28.06.2026 09:29когда кто-то, скажем, сгенерит гигантский отчет?
Потому что:
этот отчёт генерируется не моментально
“о, теперь можно и такие отчёты делать, а давайте ещё десяток”
хмм, код этого отчёта можно размножить и получить ещё кучу отчётов, тем более ИИшенка генерит абсолютно такой же код.
Много лет назад, когда мощности не поспевали за творческими изысками кодеров (а точнее стоимость покупки с какого-то момента начинала увеличиваться по экспоненте), внезапно появилась необходимость оптимизаторов. Сейчас ситуацию заливают облачками и подписками. Проблема в том, что стоимость будет увеличиваться линейно, как с той самой лягушкой.
Wesha
28.06.2026 09:29— Сколько памяти занимает Windows?
— Сколько находит — столько и занимает!© 1995.
Guestishe
28.06.2026 09:29Все это похоже на эволюцию, экстенсивно развивающиеся организмы оттачивающие метаболизм и другие системы черезвычайно эффективны. Но те кто развиваются экспансивно на заплатках опережают и занимают новые ниши.
maxys146
28.06.2026 09:29Сервис, использующий лишь жалкие 10% от выделенных ему 64 ГБ, на графике мониторинга отражается красивым, умиротворяющим зелёным цветом.
С одной стороны согласен, но с другой... Канализационные трубы делают большого диаметра не потому что люди, простите, постоянно генерируют большой поток "данных", а для того чтобы при пиковых нагрузках систему не переполнило)
akakoychenko
Статья устарела, увы. Описанные там проблемы ничто в сравнении с тем, какие монстры вырастают от возможностей LLM.
Вайтлистить IP для доступа через API надо 3 дня, а фича по поиску юзера по фамилии нужна на вчера? Эй, клодкод, навайбкодь мне скрипт под селениум, который зайдет под сервисной учеткой, пропагинирует 600 страниц в 64 параллельных воркера, поднятых в отдельных докер контейнерах, и выведет ид юзеров, где совпало.
Так... надо выпарсить имейл из текста? Вроде, деды это регуляркой делали. Но, там же ошибка закрастся может... Ну его, просто впишу туда вызов LLM, - пусть ии каждый раз имейл извлекает. Ой, тестировщик говорит, что 1 из 10 раз имейл извлекает с опечаткой? Ничего, буду вызывать LLM в цикле, пока 3 последних извлеченных имейла не совпадут
oldzoomer_ru
Так и есть. Я, например, не доверяю ИИ детермированные операции (вроде парсинга чего-либо).
Просто потому что это, по сути, умный ГСЧ.
iamkisly
скорее китайская комната
Wesha
Darkness_Paladin
Иногда лучше не знать чего-то совсем, чем иметь о предмете искажённое представление. Вот у вас именно такой случай.
Дело в том, что принцип, по которому ЛЛМ строит ответы, с точки зрения кибернетики не очень сильно отличается от принципа, по которому это делает мозг человека.
Да, мы тоже "всегда выдумываем". Вся разница -- у нас, кроме "выдумывалки", есть ещё подсистема критической оценки, которая оценивает достоверность известных нам фактов и сделанных из них выводов, поэтому человек в сомнительной ситуации может сказать "я не знаю", а ЛЛМ отвечает "я не знаю" только в заранее предусмотренных ситуациях. Например, если вы попросите её решить задачу на скорость-путь-время или на закон Ома, дав только один параметр из трёх -- это предусмотрено, она скажет "я не могу посчитать без второго параметра", это для неё типовой ответ на типовой вопрос. А вот если вы влезете туда, где у неё недостаточно знаний -- тут она часто не может отличить глюки от малозначимых фактов.
Это доделают, но потом.
Wesha
Насчёт вас не могу точно утверждать, а вот нормальные люди обычно мыслят по логике «если... то....».
Не «раз спросили про мужика и лодку, то я буду отвечать про козу и капусту», а «капуста едет туда, коза едет сюда, конфликтов не возникает».
ОБЕЩАЛКИН.ЖПГ
Darkness_Paladin
Не "мыслят", а "рассуждают". Нейронка тоже так может, если её попросить именно порассуждать, а не просто дать ответ.
Wesha
И часто Вы
онаантропоморфизируете?Нейронка может имитировать (как, собственно, и разрабатывалась). Да, в том числе и мышление. С переменным успехом.
Я тоже могу имитировать, скажем, дирижирование оркестром. Наблюдающего за мной профессионального дирижёра унесут в корчах. Так же и с нейронкой.
Darkness_Paladin
Нейронка "имитирует" мышление не больше, чем самолёт "имитирует" полёт.
Концептуально она делает примерно то же, что делает человек, только у неё пока получается не так хорошо.
Wesha
Но ведь и самолётов успехи переменные!
asdadn
Разве что по представлениям о мозге из середины прошлого века. LLM реализует сжатие текста с потерями с возможностью поиска статистически подходящего кластера информации. Внутреннее устройство тут вторично по отношению к способу "обучения". В этом и есть самое главное отличие от человеческого мозга - вы получили на вход гораздо меньше информации, чем самая глупая из LLM, прежде чем обрели возможность к синтезу новой информации. Напротив, даже у самых продвинутых LLM способность к синтезу "новой" информации весьма посредственна и обусловлена эта способность потерями при сжатии.
Darkness_Paladin
Это ОЧЕНЬ спорное утверждение. Синтезировать "как бы новую" информацию, которая на самом деле состоит из комбинаций уже известной информации -- легко и просто, с этим справится почти каждый взрослый (кроме некоторых психов), почти каждый ребёнок (кроме больных головой) и любая ЛЛМ. А вот синтезировать действительно новую информацию могут очень не все. Есть даже мнение (спорное, но...), что такой синтез не является штатной функцией нашего мозга и эта способность типична лишь для парафреников (это вид шизы, если что).
И не забывайте о том, что наш мозг возник эволюционно, и основа у него -- та же, что у более простых организмов, поэтому он заточен под то, чтоб индивидуум максимально быстро начал самостоятельное функционирование, пусть и весьма ограниченное, пока нейросети не набрали опыта. Поэтому, внезапно, сети у нас от рождения не пустые, в них на этапе физического развёртывания уже заложено что-то вроде БИОСа.
И да, наш мозг всё-таки немного посложнее современных ЛЛМок. В нём помещаются, и одновременно-параллельно работают несколько нейросетей, каждая -- заточенная под свои задачи. В частности -- специализированная нейросеть, отлавливающая в "основном потоке сознания" явно бредовые идеи, и блокирующая их.
Wesha
Синтезировать действительно новую информацию может даже игральный кубик. Вот синтезировать полезную и/или соответствующую действительности...
Darkness_Paladin
Это не новая информация. Кубик выдаёт вам одно из значений, которые у него заранее есть.
Wesha
Это Вы его просто готовить не умеете. Числа 45691223456783321387126348235791723213324138745 «у кубика» не было.
Darkness_Paladin
так кубик вам это число и дать не может, без использования арифметических (кинуть кубик много раз, перемножить результаты) или логических (тут много способов можно придумать) трюков.
Создание "как бы новой" информации, комбинируя ранее имевшуюся информацию -- это не создание новой информации. Если я придумаю, например, летающую лягушку -- это всего лишь комбинация из ранее уже известных мне понятий "лягушка" и "летать", а не что-то новое и оригинальное.
Комбинировать могут все. И взрослые, и дети, и ЛЛМ, и игральный кубик. Новая информация при этом не создаётся.
Wesha
Ну так и запишем: доказательство теоремы Ферма — это ни разу не новая информация: использовались уже существовавшие приёмы, просто в определённном порядке скомбинированные.
Darkness_Paladin
Не будем про теорему ферма. Лично я не понимаю её доказательства, да и вы, кмк, тоже не понимаете. Обсуждать то, чего мы не понимаем -- глупо.
aamonster
Т.е. сказать "ИИ, напиши мне регэксп" могут не только лишь все?
xSVPx
Не только лишь все потом проверить могут результат. В какой-то момент я попросил регэкспы больше не писать вообще. Да - это компактно и производительно, но когда у тебя для валидации этого регэкспа надо день пить валидол и раскусывать его на части, когда диаграмма не влезает по итогу на вайтборд. Ну его нафиг ..
aamonster
Ну ок, не регэксп, а код для разбора (тоже такое предпочитаю, когда регэксп слишком сложный или просто есть время аккуратно расписать парсинг). Суть в том, что иишенка должна работать, как человек – не разгребать всё руками, а писать дешёвую автоматизацию.
xSVPx
Так она так и пытается. Курсор к примеру. Но этож надо отказываться от неудачных решений, а не "х...к. х....к и в продакшн"
Darkness_Paladin
Это ещё 20+ лет назад в учебнике по регэкспам было написано -- "имейте в виду, что сложный регэксп проще написать заново, чем разобрать для проверки или изменения".
Поэтому регэкспы у нейронки надо просить с пошаговым описанием построения, чтоб можно было проверить их корректность.
xSVPx
Чтобы проверить их корректность вы должны их самостоятельно разобрать на части и завалидировать каждую часть и всё вместе.
Просто "пробежать глазами объяснения нейронки" - это немного другое.
Если вы без нейронки затрудняетесь понять "чё это ваще тут такое", то лучше их не использовать.
Я вот, часто затрудняюсь и не использую в этих случаях. Можно, конечно себя натренировать, но лучше не надо, после меня попадется кому-то ненатренированному...
Darkness_Paladin
Не разобрать, а отследить. Когда у вас есть пошаговое описание, из которого очевидно, как итоговая абракадабра собралась из простых и понятных кусочков, это можно сделать довольно легко. Когда у вас есть только несколько строк абракадабры, разобрать её на простые и понятные фрагменты КРАЙНЕ сложно.
Wesha
Вы просто их готовить не умеете ©
xSVPx
Ну если вы написали это описание, то да.
А если его написала нейронка, а для вас это абракадабра, то на том месте где вы этот код сдадите в продакшн "лучше надолго не задерживаться".
Darkness_Paladin
можете не гугля объяснить, что делает этот код:
echo "test... test... test..." | perl -e '$??s:;s:s;;$?::s;;=]=>%-{<-|}<&|{;;y; -/:-@[-{-};`-{/" -;;s;;$_;see'Лично я не могу. Ну, то есть я знаю ответ, но откуда он берётся, объяснить не могу.
xSVPx
Не буду коммитить этот код ни при каких обстоятельствах.
Некогда у нас такое в тесте было, и вопрос что будет результатом. Правильный ответ был: немедленное увольнение.
randomsimplenumber
Допустим, проект требует обфускации..
Wesha
Странный какой‑то у Вас учебник был. Если регексп разбирать не «в уме», а на бумажке с карандашиком, а то и вообще с применением специально написанных инструментов, то никаких проблем нет. И никакие недетерминированные молотки не нужны — когда детерминированный есть
Darkness_Paladin
Так никто не говорит, что разобрать нельзя. Просто за то время, пока вы его разбираете, вы его два раза с нуля заново могли бы написать.
Wesha
Зависит от степени навострюканности персонажа. Некоторые могут и с листа читать.
randomsimplenumber
Редкое умение. И что ж, умеющим читать стихи доплачивать за редкое умение?