Извращения с кодом
Как утверждают психологи «все проблемы человека происходят из детства» — все что не дали родители в юном возрасте потом обязательно проявит себя во взрослой жизни.
В моем, весьма специфическом случае такой нереализованной мечтой детства долгое время оставался... компилятор Watcom, дорваться до которого удалось лишь спустя почти тридцать лет.
Рассказываю об этом удивительном проекте.
Представим, что у нас есть массив целых чисел. Какой будет самый медленный способ их просуммировать? Будет ли это складывание слева направо, в случайном порядке или как-то иначе? Чтобы ответить на этот вопрос, мы воспользуемся слабыми местами системы управления памятью и с нуля разработаем такой паттерн обращения к данным, по которому сложение будет происходить максимально долго.
Свой PowerPoint в одном файле: редактор презентаций на HTML, который делает презентации-HTML с работающими HTML-интерактивами. Один файл, офлайн, без аккаунтов. Вайбкодил учитель физики.
Ссылка в тексте.
Есть на ютубе видео на пятьдесят минут с хвостиком, с гордым названием «худший язык программирования всех времён». Не удивлюсь, если вы подумаете, что оно про C++. Оно действительно про плюсы и я его смотрел где-то с полгода назад, ну как смотрел... пробежался на x2 с перемотками, мало ли что обиженный джун там наговорил, но добрый @alyokhin опять про него напомнил, и теперь я его посмотрел полностью. И знаете что самое неприятное? Если убрать интонацию обиженного джуна и оставить только аргументы, то процентов семьдесят там будет правды. Не «спорно», не «зависит от контекста», а буквально правда, которую любой разработчик, проведший с языком пару лет, подтвердит вам не задумываясь.
Парадокс в том, что это видео сняли про язык, на котором написана половина мира вокруг нас. Браузер, в котором вы это читаете, движок игры, куда уж без игр в моих статьях, в которую вы вчера играли, прошивка железа, на котором всё это крутится, и компилятор, которым собрали и браузер, и движок, и прошивку.
Жанр «почему C++ ужасен» на Хабре выжжен дотла и про Init-зоопарк, перегруженный static, vector названный неправильно, std::move который не move, супер медленный regex, медленный unordered_map вы всё читали раз по двадцать. Сам по себе список этих болей давно не новость, от себя добавлю, что все жалобы и примеры ниже - это следствия одного решения, и я к нему приду. Или открывайте спойлеры, там скрыта история, почему каждая часть языка получалась так, как получалась.
Начнём с того, что по-настоящему «вайблю» я где-то с ноября 25 года. До этого моё общение с LLM строилось на копипасте в ChatGPT, DeepSeek, Gemini и обратно. Рука наловчилась, и я в целом не замечала, сколько времени это всё-таки сжирает. Казалось бы, лишнее действие.
Не сказать что я злоупотребляла общением, но когда ты начинаешь кодить, ты очень уверен в себе и думаешь, что всё делаешь правильно. А как только погружаешься в процесс, начинается это… синдром самозванца, выгорание и тревога. Не сочтите меня пессимистом, но всё так и было))
Пока я училась в университете, слава богу, ChatGPT был отсталой жабой, которая через раз выдавала код с ошибкой. Поэтому я морщила нос и старалась всё делать сама — и аминь, спасибо вселенной, что всё так и было. Иначе, мне кажется, сейчас я была бы не разработчиком, а унылым вайбером, который при слове «конструктор» или «указатели» просто представляет лего и какой-нибудь г. Санкт-Петербург.
А потом случилась революция. И моя компания решила не тормозить.
Сейчас мы в процессе взрывного роста кода, когда каждый гуманитарий пишет свой фреймворк или соцсеть. Взрыв велосипедостроения в коде похож на Кембрийский взрыв, огромное количество ползающих и летающих фубля.
...или записки из палаты Линуксоида
Часто ли вам пригождается базовая обработка фото или видео? Понизить разрешение, вырезать область, нанести текст, перекодировать в другой формат и другие задачи. Раньше я пользовался для этих целей самыми разными средствами - загрузка в веб-редакторы, Paint, Photoshop, Sony Vegas.
Пока в один прекрасный момент не пересел на Linux...Удобного видеоредактора для себя не нашёл, а к рабочему процессу в командной строке и установке через dnf install уже привык (я использую Fedora). И понеслась...
Внутри - интересная справка по FFmpeg. Ничего лишнего, максимум примеров с визуализацией и компактными объяснениями. Покажу, какие задачи можно решать с помощью этого инструмента не выходя из командной строки - а таких очень много. В конце - личный опыт: зачем мне эта шизофрения понадобилась и что она мне дала.
Был такой процессор в 80х - Intel iAPX 432. Он разрабатывался в качестве преемника 8080 и изначально даже имел кодовое обозначение 8800. Intel заложила в этот процессор очень много всего - абсолютно новая архитектура, совершенно не похожая на предшественников, и даже некоторые концепции ОС, реализованные прямо в кремнии - поддержка объектно-ориентированного программирования, сборщик мусора, планировщик процессов, асинхронные коммуникации, несколько уровней отказоустойчивости и многое другое.
У меня есть книга, которая называется Game++ и несколько статей, где я разбирал какие паттерны применяются в играх и движках. В книге почти сто страниц отведено про эти самые паттерны и подробно рассказано какие они бывают, как выглядят в C++, где у них подводные камни и как их применять. Т.е. ровно те мелочи реализации, которые обычно интересно перечитать, когда вы в очередной раз решаете делать фабрику отдельным классом или попробовать обойтись std::function. Когда я её писал, мне казалось, что это будет очень полезный практический текст, и он таким и получился, и человек с опытом довольно быстро находит там нужное.
Но если читать книгу целиком, а не эти отдельные главы, то хорошо видно, как я по неопытности и уверенности молодого автора в собственной правоте взял с места в карьер и сразу начал рассказывать про реализации, как будто читатель уже всё для себя решил и его интересует только синтаксис, предположив, что мы все тут делаем условный AAA-движок, в котором сериализация неизбежна, а скрипты обязательны. В результате получился классический случай, когда книжка отвечает на вопрос «как», но обходит вопрос «а собственно зачем», а без ответа на него все ответы про «как» оказываются либо случайно-полезными, либо системно-вредными, потому что человек берёт оттуда подход, переносит его в проект или прикручивает к своей мини-игре и потом жалуется, что у него теперь полторы тысячи строк инфраструктуры на ту же мини-игру, а работает она ровно так же, как раньше, только медленнее.
Если вам вдруг надоест читать эти 106 минут, там в конце есть TL;DR секция, где собрано краткое описание.
Самая продаваемая консоль поколения имела худшую архитектуру памяти, самая технически грамотная продалась хуже всех, а самая простая в разработке принадлежала компании которая никогда раньше не делала консолей. Вы наверное узнали тут PS2, GameCube и Xbox.
Иногда шутят, что когда разработчик переносил игру с PS2 на Xbox, то первое что он делал это выбрасывал систему управления памятью и писал новую с нуля, потому что 32Мб плюс 4Мб плюс 2Мб не помещается в 64Мб.
Для чтения этой статьи вам не потребуется знать ассемблер или работать с конкретными SDK. Достаточно понимать, что такое указатель, чем стек отличается от кучи и что рендерить геометрию параллельно с её обновлением плохая идея, и что классические GPU и CPU паттерны работы по-разному нагружают память.
Там, где в тексте встречается псевдокод, он нужен для иллюстрации концепции, а не как готовый код для компиляции. Я уже подзабыл конкретные константы и названия буферов на каждой платформе, но паттерн работы всегда был примерно одинаковый.
Есть проекты, которые рождаются не из практической необходимости, а из глубоко нездорового вопроса: а можно ли сделать это совсем не тем инструментом?
Обычно, если человек хочет показать в браузере видео, он берёт video. Если хочет покадровую анимацию — пишет немного JavaScript. Он же служит и для потоковой передачи данных. Но все эти подходы слишком нормальные, а потому и недостаточно интересные.
Поэтому давайте поставим себе задачу чуть более сомнительную, чем следовало бы: воспроизвести Bad Apple в браузере без JavaScript вообще, опираясь почти целиком на CSS и немного на серверную магию.
Ну и чтобы окончательно не сбивать градус абсурда, бекенд мы тоже не будем писать на чем-то скучно-прагматичном. Если заниматься таким делом, то с достоинством: C++26 и Boost.Beast.
То лето далекого 1997 года в маленьком сибирском городке выдалось очень жарким. Шла самая его середина, когда весь азарт длинных школьных каникул успел сойти — бегать по стройкам и купаться в речке надоело, но до нового учебного года было еще далеко.
И пока утопающий в зелени городок тихо изнывал от летней жары, мы изнывали от скуки — трем юным оболтусам, слонявщимся по его улицам было абсолютно нечем заняться. Хотя в тот год случилось много всякого интересного, рассказ пойдет про самое важное событие, серьезно повлиявшее на дальнейшую судьбу и карьеру автора.
Потому что в то жаркое лето я познакомился с демосценой.
Казалось бы, современный С++ дает столько возможностей… Давайте попробуем препарировать всю эту необъятную мощь, начав с первого шага в любом языке программирования — «Hello World».
Как реализации компиляторов встречают новичка, впервые написавшему свои первые строчки кода?
> Названием «глухарь» птица обязана известной особенности токующего в брачный период самца утрачивать чуткость и бдительность, чем часто пользуются охотники
Защита программного кода — извечная битва меча и щита. Одни люди стараются создать устойчивые ко взлому программные и аппаратные продукты, другие пытаются эти решения сломать. Но что происходит, когда команда, специализирующаяся на взломе, выпускает на рынок свой продукт? Можно ли в этих обстоятельствах разработать устройство, защиту которого невозможно обойти?
Сегодня мы посмотрим внутрь флеш-картриджа для Nintendo Switch под названием MIG Switch и раскроем тайну его происхождения! Ну и в качестве побочного квеста победим защиту одного из самых современных микроконтроллеров на рынке.
Современные проблемы требуют современных решений. Когда важные люди в высоких кабинетах планомерно замедляют привычные сервисы, режут трафик и заставляют глобальную сеть работать со скоростью уставшего почтового голубя, у любого нормального инженера рано или поздно сдают нервы.
Смотреть на то, как твой вылизанный бандл грузится рывками из-за отваливающихся узлов связи, больше нет сил. Все эти бесконечные битвы за 100/100 в Google PageSpeed, микро-оптимизации LCP и внедрение Edge-кэширования теряют смысл, когда пакеты просто не доходят до адресата.
И в какой-то момент я осознал простую истину: если ты не можешь остановить глобальную деградацию веба — возглавь её.
Раз уж мы летим в прошлое, давайте лететь туда с ветерком. Под скрежет диалап-модема, с вырвиглазными GIF-баннерами, кислотными фонами и ломающейся вёрсткой.
Встречайте: Шакализатор сайтов 3000.
LLM сделали меня сильно эффективнее, расширили диапазон моих услуг, но вместе с этим почти убили ту часть разработки, ради которой я вообще когда‑то в нее пришел.
А потом мне привезли шкаф. И он неожиданно все расставил по местам.
Каждый, кто хоть раз заглядывал на Hacker News или r/ItRunsDoom, знает традицию: DOOM должен работать на всём. PDF-файлы, SQL-запросы, кишечные бактерии, тест на беременность - список бесконечен, и каждый новый порт абсурднее предыдущего
Но я задался вопросом: а можно ли запустить DOOM внутри шрифта?
Оказалось, что можно. И вот как.
Если говорить о производительности вне существующих решений в железе, то интуиция будет подсказывать достаточно простую модель выполнения, когда процессор обрабатывает инструкции, а память поставляет данные, и чем быстрее и то и другое, тем быстрее работает программа.
Но процессоры научились выполнять миллиарды операций в секунду, а память наращивает скорость доступа намного медленнее, и разрыв между скоростью вычислений и доступа к данным стал настолько большим, что именно ожидание памяти, превратилось в главный источник потерь производительности.
Ответом на это стало не ускорение памяти, а усложнение самих процессоров, которые перестали быть просто пассивными исполнителями кода и стали решать задачи управления потоком данных: выполнять инструкции вне порядка, переупорядочивать зависимости и на каком‑то этапе подошли к идее спекулятивно исполнять код, который, возможно, вообще не понадобится.
Предсказание ветвлений стало один из ключевых механизмов в этой системе, которая должна была снять часть времени простоя потока вычислений, но если удачное предсказание стало возможностью начать дорогие загрузки заранее и скрыть их латентность, то ошибка предсказания скрывает не только потерянные такты, но и зря использованные ресурсы памяти: шину, буферы загрузки, пропускную способность контроллера и сами кэш‑линии, которые могли бы быть заняты полезными данными.
Именно здесь возникает интересный и неочевидный компромисс, позволяющий с одной стороны, писать branchless‑код и полностью избавиться от ошибок предсказания, а с другой лишающий процессор возможности работать на опережение и запускать доступ к памяти раньше времени. Но в зависимости от того, где находятся данные в памяти выигрывать будет то один, то другой подход.
Если вы собираетесь писать branchless код, надо помнить как именно спекулятивное выполнение и предсказание ветвлений взаимодействуют с подсистемой памяти, потому что «лишняя работа» иногда ускоряет программу, а в некоторых случаях попытка сделать код более «предсказуемым» приводит к обратному эффекту.
Если кратко, то цель: компилятор некоторого подмножества языка Си на C++, который работает в compile-time. Компиляция будет происходить в кастомный байт-код для дальнейшего выполнения в ВМ уже в рантайме.
AI должен был сделать мою работу легче. Он сделал. Только вместе с этим куда-то пропало ощущение, что я вообще что-то создаю