Comments 34
На сколько я понимаю, если рассматривать с точки зрения игр, то потребуется уже оптимизация другого типа. Самое раздражающее, что может случиться в процессе игры - статтер, т.е. замирание картинки на несколько десятков или сотен миллисекунд. И разработчикам придётся следить чтобы не было такой ситуации, когда на новый кадр придётся запустить слишком много таких вот мелких нейросетей для генерации новых тексур. И, опять же, на сколько я понимаю, при загрузке текстур с SSD или из RAM в VRAM используется DMA, т.е в процессе загрузки все процессоры продолжают работать и выполнять текущие вычисления, а в данном случае GPU должен будет отвлечься от текущего кадра и создать текстуру, которая будет использована в ближайшем будущем, и это тоже налагает некоторые органичения.
Классический трейд-офф: мы нагружаем ГПУ вычислениями, чтобы разгрузить шину памяти, которая чаще всего и становится причиной статтеров. Насколько я знаю (и я это косвенно затронул в статье), современные решения используют тензорные ядра для декомпрессии прямо в шейдере.
Для таких фоновых распаковок Хуанг давно встроил тензорные ядра, они молотят матрицы параллельно основному рендеру и шину памяти вообще не вешают
Главная цифра в статье получена звуком. И достигнута простым способом - сначала искусственно увеличим, потом снизим размер до оригинала.
Но в реальных AAA играх сейчас та же озвучка - это хорошие актёры, которые играют как в кино или театре. Так что давайте попробуем на реальной задаче: возьмите монолог Гамлета в исполнении Высоцкого (около 3,4 Мб в mp3, похоже на цифру из таблички) и сделайте из него 1.2 Кб (тоже из таблички). И чтоб разницы не было заметно.
Справедливо, MIDI-арпеджио и реальный голос это вещи разного порядка, и сжать монолог Гамлета в 1.2 Кб без потерь невозможно в принципе. Но для фонов и эффектов синтез до сих пор мощный инструмент. А искусственное раздутие было как раз для подсвета избыточности современных игр, где имхо можно было обойтись легким процедурным синтезом.
Суть статьи не в том, чтобы сделать из голоса актера миди-файл. Просто фоновые шумы типа воя ветра или шагов действительно проще синтезировать алгоритмом на лету, чем тянуть толстыми wav-файлами
Это на эффекте масштаба проявляется. Просто монолог Гамлета таким образом воссоздать нереально. А теперь берем TTS современную(условно говоря 1 гб), обучаем модельку голосу Высоцкого (для примера положим что она будет весить 10 гб), и затем даем задачу - озвучить всю Википедию. И вот тут уже эффект масштаба работает: даже в mp3 наша "аудио-википедия" после такого "развертывания" будет весить в сотни раз больше и модельки, и оригинального текста, и датасетов, использованных для создания "голоса Высоцкого". Вот уже и экономия. Можно не держать аудиоверсию каждой статьи на сервере, достаточно будет самой статьи + TTS с моделями, при этом если не нравится Высоцкий - ну выберите скажем модель Володарского и она озвучит то же самое по любой статье, а весить будет те же + 10 гб. Разумеется даже такое "ии-сжатие" требует ресурсов. Ну так любое сжатие - расжатие их требует, даже по классическим алгоритмам. А тут мы имеем алоритм хоть и с потерями, но вполне себе рабочий, как и с mp3.
Расскажите, что делали 34гб звука в игре Titanfall 2014 года.
Они wav преобразовывали в формат 01001010100, где каждый бит превращался в символ (распухание в 8 раз), или - как им это удалось, если даже в WAV такой дикий объем не был бы получен?
Сказать, что это звездец, значит ничего не сказать.
Вчера общался с техподдержкой очень большой компании занимающейся промышленной автоматикой.
Техподдержка не в курсе что есть браузеры не основанные на хроме.
Толи плакать то ли смеяться.🤦🏼♂️
А зачем им забивать голову лишней инфой? Хромиум монополизировал львиную долю рынка, под него пишется весь корпоративный софт, остальное проблемы тестировщиков
Кхм... ну как лишняя информация...
Ссылка которую мне прислали не открывалась. На мой вопрос: есть ли зависимость от браузера, ответили мне отрицательно.
В браузере на основе хрома, ссылка открылась замечательно.
Если эти же люди поддерживают промышленные контроллеры выпускаемые компанией где они работают... Пожалуй я буду ставить в шкафы управ оборудованием контроллеры другого производителя.
Мне получается буквально ответили по "бородатому" анекдоту про программиста на стрельбище: "От меня все пули ушли. А то что они в цель не попали, это уже проблемы на вашей стороне".
И какие же у нас остались известные браузеры не на основе хрома, которыми пользуются 3 калеки ?
Доля всех Chromium-based уже выше 85%.
Консоль и вкладку Network открывал посмотреть, почему ссылка не открывалась ?
Эпоха .kkrieger была крутой демосценой, но в коммерческой разработке время программиста стоит в тысячи раз дороже гигабайта на SSD. Никто не будет сидеть и писать процедурную генерацию травы, если можно купить готовый ассет за доллар
Никто не будет сидеть и писать процедурную генерацию травы, если можно купить готовый ассет за доллар
А потому что это называется "разделение труда". Но к проблеме, озвученной в посте это имеет никакое отношение. Тут скорее, "не будут писать процедурную генерацию травы, а нагенерят всю возможную траву заранее хитрым методом в 3дмаксе и засунут в ассет"
Вы же врете про картинку с 256 цветами.
magick /tmp/part2_orig.png -format "%k" info: 130885
Реальные 256 цветов выглядят вот так:
И разница очень-очень видна
Просто 256 цветов надо уметь правильно готовить :)
С дизерингом по Флойд-Стейнбергу они выглядят так:
Другой вопрос что у автора статьи 24-битная картинка в 7 раз больше места заняла, чем 8-битная - и это на подтасовку фактов таки похоже
Про то что на последней 4 цвета тоже неправда :)
Нет, идея понятна - желтый, оранжевый, зеленый, темно-синий и дизеринг. Но технически на четвертом примере 90 тыс уникальных цветов.
Отвечая на вопрос заголовка: наверное, потому, что браузер умеет делать в 7000 раз всего больше, чем старая игра. Многие не подозревают, сколько разных API и стандартов туда понапихано (в том числе и устаревших, но без которых где-нибудь что-нибудь сломается).
Ну, это конечно справедливо, что Хром посложней, чем "Мариво" да и на Денди его не накатишь. Но проблема-то актуальная поднимается: на оптимизацию и даже на сквозное и всеобъемлющее тестирование забивается огромный, гигантский, жирный как откормленный фритюрным жиром свин, болтяра. И расхлёбывать это все вынуждены мы по итогу.
Текстуру травы можно сгенерить из 28 байт:
import numpy as np
from scipy.ndimage import zoom
Вы бы для честности ещё размер среды исполнения добавили. А то 28 байт плюс пакет numpy... О-о
Приветствую!
Я тут готовлю заметки для статьи про облегчённые методы оптимизации.
Вопрос состоит в том, возможно ли добиться большого прироста производительности, прилагая в разы меньшие усилия. Я думаю, что это в некоторых случаях возможно. По крайней мере, программисту стоит знать базовые приёмы.
Есть три направления оптимизации - оптимизация расхода памяти, оптимизация времени выполнения и оптимизация времени компиляции. Обычно мы приходим к тому, нельзя прибавить одно, не убавив что-то другое.
Меня волнует в первую очередь оптимизация времени выполнения. А вот время компиляции релизных сборок я не прочь как раз увеличить!
Вообще, очень медленная операция в современных компьютерах - это чтение и запись в оперативную памяти. А ввод вывод бывает порой ещё хуже...
По этому очень важно, чтобы ваш код как можно меньше бегал за данными в плашки, и как можно больше работал с данными в кэше процессора (желательно L1) а то и в регистрах.
Вы наверное все знаете, что есть O большое, бывают алгоритмы константные, бывают линейные, логарифмические, квадратичные, экспоненциальные...
Обычно, чем меньше O большое, тем быстрее работает алгоритм.
Например, время поиска элемента в хэш-таблице всегда примерно одно и тоже, и не должно меняться в зависимости от того, сколько в ней элементов. А бинарный поиск работает за логарифмическое время.
Казалось бы, хэш-таблица всегда должна выигрывать. Ан нет! O большое позволяет оценить примерную скорость роста затрат по мере увеличения входных данных. Кроме этой оценки есть ещё и коэффициенты. Массив, по которому мы проходимся бинарным поиском может уместиться в кэш, а хэш-таблица нет. Может быть, пока она высчитывает хэш, мы уже десять раз успеем бинарным поиском пройтись по массиву.
Это реальный случай. Кажется, тогда код запускался на микроконтроллере.
Я слышал фразу, что самый главный приём оптимизации - это профилирование. Чтобы что-то оптимизировать, нужно сначала это измерить.
Буду рад, если вы подскажете и другие приёмы.
Где-то ещё я слышал, что оптимизация - это во многом перебор различных приёмов. Вся штука в том, что они друг-друга нивелируют, и нужно подобрать такую комбинацию, которая даст наилучший эффект.
Вообще интересно, что будет, если дать ИИ агентам фрагмент кода, и таблицу способов, как его можно оптимизировать. Пущай перебирает! Небось так можно и глобально оптимальный вариант найти. Главное потом проверить, что он ничего не поломал...
Как жалко, чтоб большинство языков программирования не позволяют доказывать корректность, как мой ненаглядный Lean!
В компиляторах есть такая техника - супероптимизация. Она состоит в том, что мы берём кусочек кода, который хотим оптимизировать, и перебираем все возможные варианты машинного кода, меньшего определённой длины. Так мы ищем самый быстрый фрагмент, про который доказано, что он делает то же, что и исходный код. Ясное дело, что там есть много-много хитростей, чтобы отсечь большую часть невалидных вариантов, но всё равно это работает ужасно медленно.
Обычно супероптимизацию не применяют. Я слышал, её могут использовать, чтобы скомпилировать небольшие кусочки кода, которые потом будет использовать компилятор. Что-то вроде библиотеки оптимизированных фрагментов.
На вашем диске лежит семь одинаковых моделей птицы Додо. Не благодарите — это ARK заботливо положил их вам в каждое DLC.
Раньше Super Mario Bros весила 40 КБ. Сейчас одно обновление Chrome — это ~7 000 таких Марио. Как мы дошли до жизни такой, и почему все идет по кругу?
Потому что более ёмкие винчестеры сами себя не продадут!
Обещали все за 10 строк кода. А получилось слишком много кода. Не очень понятно где тут новый подход , если тот же плейврайт и создан для тестирования интерфейсов локально. Теперь к тестам еще и UI тесты, как будто мы делаем интерфейс для машин, а не таких же людей. И почему нельзя в таком случае сразу использовать storybook, когда там все тесты интерфейсов уже встроены? Получается так или иначе вы будете тестировать, и вручную, и тестами. Какой в этом смысл? Добавить работы?
Mipmap экономит видеопамять? Он увеличивает ее использование в 1.333 раза. Он очень ускоряет рендер из-за текстурного кеша и устраняет визуальный джиттер
Текстуры сжаты в dxt/bc и прочие не спроста. Это сжатие в видеопамяти. Из jpeg их конвертируют в эти форматы и процесс очень медленный - на загрузке игры не сделать
И подобных косяков в статье много.
Первая версия нарочито раздутая … Звук поедания яблока — эффекты в WAV (44,1 кГц; 16 бит), потому что «а вдруг кто-то услышит разницу»
Честно говоря, непонятно, как это связано с семикратным хранением модельки из примера в начале. По-моему, это очень разные кейсы.
Не использовать сжатие с потерями потому, что кто-то действительно может услышать/увидеть разницу (в данном случае не знаю, я не звуковик) — это одно. А отсутствие центрального наследуемого (расширяемого) репозитория ресурсов, что приводит к копипасте огромных размеров — совсем другое.
В первом случае мы тратим плоды прогресса (память/ЦПУ/ГПУ) на то, чтобы сделать продукт лучше. Во втором — просто выкидываем их ни на что.
дело не только в ресурсах, суть в том, что ресурсами, которые отправляются на карточку в контексте уровня браузер, надо управлять потоками данных, соответственно это похоже на сборщик мусора, соответственно нужно окно, нужен инстанс на js наверно, далее ресурсы, и потоки подключений, итак сколько гигабайт выделит 1 вкладка без гонки ресурсов, минималка это 300 мегабайт с учетом управления кучи, и еще учитываем, что иногда куча не отдаст в ОС память сразу если вкладка открыта, соответственно, даже не знаю что и сказать, на клоне майнкрафта кстати у вас будет такая же ситуация из-за многопоточки без сети, где минималка без сетки около 300 мегабайт на бесконечный мир только ландшафт без растительности.
флаг дирти на вкладку можно проставить только по истечению наверно таймаутов + вкладка закрыта, и прочее и прочее, там как не крути пылесос на слотах будет.
тоесть там для поддержания рабочего процесса - всякие хитрые kqueue и прочее, изоляции какие-нибудь кушают тоже поидее...
так-то на поверхности кажется, что оно всё не нужно, и без крос-платформы можно сделать легче, но на самом деле это будет счёт на спичках, ну а если делать полный фарш, то придём к тем же метрикам по памяти и прочему или что-то потеряем типо.
потом сайты или вкладки имеют разные длины так скажем, а это значит выделить или добавить планка увеличивается, кароче еще нелинейность тоже имеет место быть.
В статье на картинке 40 Кб занимают дискету, 96 Кб - 10 дискет, а 4,6 Мб занимает CD-R диск.
Приемлемо (с)
Раньше были компьютерные игры, теперь создают целые иные цифровые миры!
Но почему вы сделали исключение для годов и не стали ставить пробел после первый цыфры? В чём логика?
Как вы не видите дич в том, што в заголовке цыфра 1 осталась на первой строке, а на вторую ушли три нуля? Ну должна же возникать мысль "а правильно ли я делаю?". По правилам руссково языка рекомендуетса отделять нули только после 4 цыфр, иначе надо ставить пробел и в годах: 2 026 год.
Почему Chrome весит 7 000 Марио или как сжать «Змейку» в 1 000 раз