Каждый был тем, кто адаптируется в новой команде, и тем, кто наблюдает за этим процессом со стороны, многие не замечают этого перехода, а те, что замечают редко придают значение ранее невидимым вещам. Я раньше тоже думал об адаптации в компании, как о своей личной проблеме, а теперь, оглядываясь на этот период "новичка", отмечаю один и тот же спектакль с предсказуемыми актами, но разными актёрами и почти одинаковым финалом.

Навыки есть? А если найду?

Первое, что бросается в глаза (особенно если взяли опытного) это момент понимания что его знания не полностью переносимы. Люди реагируют на это по-разному, очень по-разному и кто-то начинает защищать тот стиль в коротом это делали на прошлом месте (к сожалению, и меня это касается), других не видно несколько недель, третьи продолжают традиции кофейного геноцида и компания тут не важна, четвертые бросаются переписать всё, что кажется странным.

Но проблема не в том, что новый человек чего-то не знает, что нормально и ожидаемо, просто опытный специалист часто не осознаёт насколько узкой была его специализация на предыдущем месте. Имена проектов говорить не буду, дабы не навлечь неодобрение людей с которыми работал.

Как-то к нам пришел очень крутой разработчик физики, очень... его переманивали год на разные проекты и под разными предлогами, а физику на том проекте настраивали через таблицы в текстовых файлах и lua-скрипты, а не через движковые параметры (ну вот так исторически сложилось), и первые недели он все время пытался что-то переписать, исправить, доработать, и 90% его изменений заворачивали на ревью, что конечно не добавляло настроение ни ему, ни команде. И визуально он работал заметно медленнее джуна, который пришёл месяцам раньше и просто принял такое положение вещей как данность, но смог пофиксить пару сложных багов, которые висели в беклоге пару лет.

Конечно, это было неприятно (человека в итоге вызвали на разговор) для опытного, потому что он чувствовал себя некомпетентным, и еще это было неприятно для тех, кто его затащил в студию и ждал результата, начиная сомневаться в правильности решения.

Про C++ часто шутят, что любую вещь можно сделать пятью разными путями, четыре из которых компилируются, три работают, а два правильные, но один зависит от фазы луны. Часто такие шутки и идиомы откладываются в коллективной памяти сообщества какой именно из этих путей правильный в каждой конкретной ситуации.

Большинство этих примеров родилось в эпоху до C++11, когда у языка ещё не было ни умных указателей в стандарте, ни move-семантики, ни constexpr, ни концептов, и приходилось руками собирать из шаблонов и перегрузок некоторые конструкции, которые в более поздних стандартах язык даёт почти бесплатно. Многие идиомы, примеры и идеи стоит читать в двух смыслах сразу, как исторический артефакт, объясняющий «почему старый код выглядит вот так», и как живой приём, который всё ещё применяется в движках и играх.

Разработка игр тут не случайно, потому что игровой движок это обычно место, где абстракции встречаются с профилировщиком, и проигрывают ему чаще, чем хотелось бы. А легаси паттерны цветут и пахнут из-за чьих-то забытых в углу костылей, но большинство вещей вполне правильны, применяются и спасают от ошибок. Многое из этого спрашивают если не дословно, то хотя в паре слов, хорошие лиды на собесе, перед тем как позвать вас в команду, и просто взяв рандомо 5-6 пунктов можно составить впечатление, сталкивался ли новый человек с определенными проблемами.

Когда я собирал оглавление Game++, раздел про идиомы, идеи, паттерны и механизмы C++ планировался шестым и завершающим, и должен был занять страниц сто, по одной на каждый пункт, но чем дальше я собирал материал, тем яснее становилось, что каждая секция тянет за собой историю, а каждая история требует контекста, а каждый контекст в игрострое никогда не бывает простым. В итоге текст разросся до размеров, при которых он просто сломал бы структуру книги, и мне пришлось выбирать между «урезать до неузнаваемости» и «отпустить жить отдельно». Пришлось выбрать второе.

Перед вами то, что могло бы стать половиной Game++, но стало самостоятельным материалом. Здесь собраны идиомы, идеи, паттерны и механизмы C++, которые сложились в сообществе за несколько десятилетий и продолжают жить в кодовых базах игровых движков, иногда под своими именами, иногда под другими, иногда вообще без имён, потому что их давно перестали объяснять. У большинства имена все же есть, есть и история с ответом почему именно так, а не иначе.

Вероятно вам потребуется вспомнить некоторые правила вывода шаблонов, и что такое конструктор и деструктор, чем стек отличается от кучи, что у объекта есть время жизни, но это не точно. Я также намеренно убрал обработку краевых случаев и разные проверки из кода, которые в реальном коде заняли бы половину всего текста и утопили бы саму мысль в деталях. Паттерн механизма в моем случае важнее конкретной реализации, и почти каждая из них существует в десятке вариаций под разные компиляторы и стандарты.

UI это та часть игры, которую игрок замечает только когда она сломана, а программистам она доставляет проблемы постоянно, потому что именно UI оказывается тем местом, где сходятся рендер, логика, ввод, локализация, аллокации и хотелки дизайнеров. В прошлой части я разобрал почему написать хороший UI сложно, долго и дорого.

Теперь попробую разложить архитектуру UI по нескольким осям, именно осям, потому что один и тот же UI может быть diegetic по расположению, immediate mode по хранению, reactive по потоку данных, flexbox по лейауту и векторным по рендеру одновременно, а проблемы начинается там, где люди пытаются совместить несовместимое.

Если показать любому игровому программисту лекции про пользовательский интерфейс года эдак 2006, а потом показать ему что он наклодовал в современной игре, то он узнает в них почти всё, но с небольшими оговорками. Поменялись названия API и язык кодогенерации, но архитектура и основные идеи остались те же: дерево контролов, свойства с рефлексией, связи между свойствами, шаблоны, абстракция над движком и вечная война за пиксель-в-пиксель.

Пользовательский интерфейс в играх это место, где встречаются все худшие архитектурные требования сразу, на них накладываются требования дизайнера UI, который сидит через стол и просит, чтобы окно появлялось «вот так с анимацией», причем «вот так» зависит выпил ли он чашку кофе или еще нет. Вечером приходит художник, который нарисовал кнопку в фотошопе и хочет, чтобы на экране она выглядела пиксель-в-пиксель, и вы обязаны учесть эти требования, потому что в этой цепочке принятия решений художник стоит ближе к финальной картинке. А еще есть программист игровой логики, который не хочет знать, как называется конкретный лейбл, и не должен этого знать.

Под конец приходит локализатор, который превратил «1 enemy / 2 enemies» в «1 враг / 2 врага / 5 врагов» и зависимость от рода. Иногда заскакивает инженер по портированию, которому надо то же самое окно крутить на PC, консолях или мобилках с разными разрешениями и соотношениями сторон, ну на него пофиг, он сам себе программист и если что, допишет код. И всё эти требования должны как-то жить вместе.

Большая часть студий начинала с написания системы GUI «по месту», т.е. для конкретной игры, под конкретный рендер, с захардкоженной раскладкой, а когда выходила следующая игра, выяснялось, что вытащить старый GUI почти невозможно. Такой UI насквозь срастается с рендером, инпутом, звуком и игровой логикой и каждый следующий проект начинается с фразы «давайте сделаем нормально один раз», и каждая следующая итерация показывала, что «нормально» это не одна задача, а много и одновременно.

Не переключайтесь, будет еще вторая часть про то как этот самый UI мучали от игры к игре...

(с)
На дворе непростой 2026, по всему миру волнами идут нехорошие события, что отражается и на нашем родном ИТ: массовые сокращения, повальное урезание бюджетов, закрытия и банкротства компаний. На фоне этих печальных событий, многие (даже опытные и достойные) сейчас теряют работу в ИТ, что вызывает у тех кто остался нездоровый энтузиазм и даже злорадство
(с)

Чтож, у @alex0x08получилось отличное драматическое вступление, вот только где бы мы сейчас были без иных "случайных" людей. Так навскидку человек, придумавший жанр, который сейчас собирает половину кассы всей игровой индустрии, был страховым агентом. Жанр называется RPG, человека звали Гэри Гайгэкс, а изобрел он всего-то Dungeons & Dragons.

И это не единичный случай, и почему-то принято стыдливо забывать об этом каждый раз, когда в очередной статье кто-то пишет «без профильного образования даже не думай». Могу сказать что история игровой индустрии - это история юристов, домохозяек, лётчиков, капельдинеров, экспортёров консервированной фасоли и недоучившихся архитекторов, которые пришли непонятно откуда и построили всё, во что вы играли последние сорок лет.

Так что в следующий раз, когда вы откроете статью с заголовком в духе «можно ли войти в IT без опыта/образования/после тридцати/из совсем другой профессии», просто пролистайте этот список ещё раз. Вы всё ещё против случайных людей в IT?

За карьеру получилось у меня поработать под руководством нескольких тимлидов, и я уже стал забывать их по именам, зато остались в памяти их любимые хоткеи. В некоторых описаниях вы, возможно и своих узнаете, а может и моих.

Обычно те тимлиды, к которым я попадал уже не писали код, или делали это очень редко. Чаще тимлид брал код из одного места, как-то его менял и переносил в другое, или не переносил, или переносил и делал задачу его починить. Всё, что делало большинство тимлидов, так или иначе было связано с чтением чужого кода. Но не весь код одинаков, поэтому разные способы его перемещения работают с принципиально разной скоростью, надёжностью и сопровождаемостью.

Алексей Пажитнов написал «Тетрис» в 1984 году на «Электронике-60», работая в Вычислительном центре АН СССР, и эта игра до сих пор входит в любой список «самых влиятельных видеоигр всех времён». В том же 1984 году в США уже четвёртый год подряд продавался Pac-Man, а в Японии Nintendo готовилась к экспорту NES. В том же году два британских студента на ZX Spectrum написали Elite с процедурной генерацией восьми галактик в 22 килобайтах памяти.

К началу 1992 году СССР закончился. «Тетрис» стал собственностью Nintendo через цепочку посредников, и никаких других советских игр мирового уровня за следующие десять лет так и не появилось, хотя отдельные студии делали хорошие проекты, я буду считать 90-е наследием советов. А вот вопрос, который мне кажется куда интереснее, чем «почему так получилось»: почему в одно и то же время одна и та же страна могла спроектировать систему наведения «Бурана» с автоматической посадкой по радиомаякам, но не могла сделать массовый игровой автомат уровня Space Invaders?

В ответ часто слышал «не было рынка, не было капитализма, не было конкуренции». Я в это не верю. Не верю, потому что отсутствие рынка не мешало тем же людям спроектировать «Энергию-Буран», Ту-160 и атомный ледокол «Арктика». А вот качественный массовый телевизор «Рубин» в той же стране делать почему-то не получалось. И качественную массовую игру тоже.

Не надо быть матёрым геймдизайнером и знать, что такое ECS и GOAP, достаточно понимать, что игра - это продукт, который собирается из кода, графики, звука, геймдизайна и тестирования, и что каждая из этих веток требует отдельных людей с отдельной экспертизой. Дальше будет немного арифметики и исторических примеров.

В прошлой статье я разбирал паттерны и необходимость компромиссов в реальной разработке, и там была одна мысль которую я намеренно оставил в стороне. Паттерны редко живут в одиночку, и любая реальная система это не один паттерн, а несколько, склеенных, скрученые, слепленных, и местами прибитых сбоку гвоздями, и каждый из них закрывает только часть проблемы. Менеджер ресурсов это, наверное, самый показательный пример такой склейки, потому что снаружи он обычно выглядит как пару строчек видаLoadTexture("bark.dds"), а внутри это кэш, политика дефолтов, механика восстановления после сбоя и ещё полдюжины вещей, каждая из которых прошла через пот, кровь и пиксели и осталась в архитектуре этой системы.

Если открыть любую книгу по разработке игр или игрового движка и попробовать найти определение "игровой ресурс", то получится что ресурс - это набор данных, которые были загружены или созданы с конкретными параметрами. Любые уточнения вроде «текстура», «меш», «звук» или «шейдер» здесь уже будут лишними, потому что нам важна не природа данных, а что они существуют именно определенной форме.

Понятие "определенная форма" тем не менее тоже звучит абстрактно, поэтому люди предпочитают использовать "текстуру", "меш", "звук" и т.д. Но одну и ту же текстуру wall.dds, которую можно загрузить в DXT5 со сжатием, sRGB и mip-фильтром box, а можно без сжатия, в линейном пространстве и с другим фильтром. Формально у нас был один файл на диске, но с точки зрения ресурсного менеджера теперь это два разных "ресурса", потому что их параметры различаются. Подмена одного ресурса другим в рантайме может сломать игру, потому что игра ожидает определенных данных для шейдера, которая изменилась после фильтра или определённую раскладку мипов, которой может не оказаться.

Более явный пример для шейдеров будет, когда lighting.fx, скомпилированный с дефайном SIMPLE_BUMP_MAPPING, и lighting.fx, скомпилированный с PARALLAX_BUMP_MAPPING, физически выглядят в исходниках как один файл, но дают два разных пайплайна, со своими константными буферами и со своими ожиданиями к набору текстур, а если ресурсный менеджер этого не понимает, то он либо начнёт раздавать второй вариант, когда просят первый.

С мешами история та же самая, и ship.mesh, загруженный в менеджере ресурсов, и тот же ship.mesh, лежащий в GPU это два разных объекта, у которых даже время жизни и поведение при потере устройства будут отличаться, не говоря уже о том, что первый мы можем менять, а в второй нет.

У меня есть книга, которая называется Game++ и несколько статей, где я разбирал какие паттерны применяются в играх и движках. В книге почти сто страниц отведено про эти самые паттерны и подробно рассказано какие они бывают, как выглядят в C++, где у них подводные камни и как их применять. Т.е. ровно те мелочи реализации, которые обычно интересно перечитать, когда вы в очередной раз решаете делать фабрику отдельным классом или попробовать обойтись std::function. Когда я её писал, мне казалось, что это будет очень полезный практический текст, и он таким и получился, и человек с опытом довольно быстро находит там нужное.

Но если читать книгу целиком, а не эти отдельные главы, то хорошо видно, как я по неопытности и уверенности молодого автора в собственной правоте взял с места в карьер и сразу начал рассказывать про реализации, как будто читатель уже всё для себя решил и его интересует только синтаксис, предположив, что мы все тут делаем условный AAA-движок, в котором сериализация неизбежна, а скрипты обязательны. В результате получился классический случай, когда книжка отвечает на вопрос «как», но обходит вопрос «а собственно зачем», а без ответа на него все ответы про «как» оказываются либо случайно-полезными, либо системно-вредными, потому что человек берёт оттуда подход, переносит его в проект или прикручивает к своей мини-игре и потом жалуется, что у него теперь полторы тысячи строк инфраструктуры на ту же мини-игру, а работает она ровно так же, как раньше, только медленнее.

Если вам вдруг надоест читать эти 106 минут, там в конце есть TL;DR секция, где собрано краткое описание.

Недавно я был на отраслевой конференции, где встретил пару знакомых, с которыми начинал ещё в питерских студиях. В отличие от меня, который всегда работал на «дядю», они в какой-то момент выбрали тернистый путь создания инди, своих студий и (судя по тому, как они заказывали напитки) этот путь оказался значительно тернистее, чем выглядел десять лет назад. Хотя глаза у них горели ровно так же, как тогда. Что тогда, что сейчас эти горящие глаза одновременно вызывали и зависть, и лёгкое подозрение, что они просто не успели ещё по-настоящему устать.

Потом мы разговорились. Пусть будет Костя, с которым мы когда-то делали "симсов", уже год пилит гачу для очередных китайцев, чтобы платить зарплаты своим ребятам. А пусть будет Лёша, держит студию из четырёх человек и занимается код-ревью аишных коммитов, но теперь уже для индийских ребят, только тех, которые в солнечной Калифорнии, а не в прекрасном Дели. Тут я вспоминаю своё четвертьвековое легаси, и когда мне говорят, что искусственный интеллект скоро заменит программистов, тихо радуюсь: после стольких лет разработки большинство систем там устроено настолько коряво, что любая нейросеть сжирает все токены, просто пытаясь осмыслить, куда она попала. А значит, как минимум до конца поддержки игры у меня будут задачи.

Про запиливание гач и работу на китайцев инди-студии не очень любят рассказывать вслух, потому как ломается стереотип «свободных и независимых», особенно на отраслевых мероприятиях, где все ходят с одинаковыми бейджами и одинаково уверенными лицами. В целом попасть в инди относительно несложно, а вот прожить в нём дольше, чем длится цикл разработки одного среднего проекта, оказывается задачей со звёздочкой.

В прошлой статье я разобрал, как работает квалифицированный поиск и как using namespace участвует в нём только в качестве запасного варианта, когда собственных объявлений в указанной области нет. Компилятор сначала смотрит, что объявлено непосредственно в текущем контексте, и только при неудаче переходит к именам, подмешанным через директиву using. Казалось бы, схема прозрачная и предсказуемая: есть область поиска, есть приоритет явных объявлений, есть «правило N-объявлений» как страховка.

Но как только мы переходим от переменных и функций к более общим механизмам в коде, эта прозрачность сразу начинает ломаться, причём в самом обыденном коде, который пишет каждый разработчик с первых дней обучения. По правилам языка мы можем разместить директиву using namespace где угодно, но если в области, указанной в квалификаторе, что-то объявлено явно, квалифицированный поиск найдёт именно это объявление, и лишь если явно объявленного имени нет, компилятор начинает учитывать имена, ставшие видимыми через using namespace, и так далее по цепочке.

Но тут есть скользкое место, о котором умалчивает большинство учебников и курсов, обходя вниманием работу с операторами. Например оператор сдвига влево <<, может быть определён в любом пространстве имён.

Есть такая старая и немного протухшая дискуссия про 10x программистов. То ли они существуют, то ли это миф стартаперов, то ли это просто мечтания менеджеров про «давайте наймем одного волшебника вместо команды». В презентациях, постах и разговорах эта тема всплывала регулярно, обычно где-то рядом с «нам нужны сильные люди», «у нас маленькая команда» и «дедлайн вчера», а уж на фоне AI-агентов, так и вовсе расцвела опять буйным цветом.

Меня в этой теме всегда смущало, что под 10x часто пытаются запихнуть вообще всё: скорость написания кода, умение чинить баги, знание проекта, способность не делать больно проекту, опыт коммуникации с менеджментом, архитектурный вкус и опытный опыт, готовность сидеть ночью и баф на везение. А потом из этого делают красивую легенду про человека, который работает в десять раз быстрее остальных.

Мечты ПМа, это все же мечты, а в реальной жизни всё скучнее и интереснее одновременно. Я видел людей, которые действительно делали задачи сильно быстрее других. Видел в open-source, видел в игровых проектах, видел на старом коде, видел в маленьких библиотеках. Но почти всегда причина была не в том, что человек родился с коэффициентом x10 и бафом на скорость набирания буковок, а в том, что за его скоростью стоял какой-то накопленный капитал, вроде знания проекта, инструмента, узкой экспертизы или годов ковыряния в похожих задачах.

Самая продаваемая консоль поколения имела худшую архитектуру памяти, самая технически грамотная продалась хуже всех, а самая простая в разработке принадлежала компании которая никогда раньше не делала консолей. Вы наверное узнали тут PS2, GameCube и Xbox.

Иногда шутят, что когда разработчик переносил игру с PS2 на Xbox, то первое что он делал это выбрасывал систему управления памятью и писал новую с нуля, потому что 32Мб плюс 4Мб плюс 2Мб не помещается в 64Мб.

Для чтения этой статьи вам не потребуется знать ассемблер или работать с конкретными SDK. Достаточно понимать, что такое указатель, чем стек отличается от кучи и что рендерить геометрию параллельно с её обновлением плохая идея, и что классические GPU и CPU паттерны работы по-разному нагружают память.

Там, где в тексте встречается псевдокод, он нужен для иллюстрации концепции, а не как готовый код для компиляции. Я уже подзабыл конкретные константы и названия буферов на каждой платформе, но паттерн работы всегда был примерно одинаковый.

У разработчиков игр есть довольно странная профессиональная болезнь, когда после рабочего дня, проведенного за тасками и кодом хочется открыть ноутбук и снова писать код, только уже «для себя». Большинство моих коллег по цеху, придя домой тратят 1+ часов чтобы: поделать свой движок или переписать/помодить/любимую/старую/новую/другую (нужное подчеркнуть) игру или собрать какую‑нибудь библиотеку, или починить инструмент, который всех раздражает. Не знаю, может эта заразно и гуляет по студиям, а может это просто кусочек творческой атмосферы, который ты уносишь из офиса, и он некоторое время живет вне этого пространства.

Часто бывает что маленький проект, который был на «пару вечеров» внезапно превращается в несколько лет жизни. Я много раз видел это снаружи и изнутри: СorsixTH, 0AD, Akhenaten, Cytopia, StoneKingdoms, (тут больше open‑source‑games) очень разные проекты (из тех куда я комитил), но все они хорошо показывают одну и ту же вещь, что пет‑проект почти никогда не остаётся «просто маленькой штукой». Он либо умирает, либо начинает требовать от автора взрослого отношения и тянет за собой архитектуру, поддержку, документациу, общение с коллегами по цеху и теми кто просто играет, разбора багов, релизов и неприятных компромиссов.

И главный вопрос тут не «как найти мотивацию», а точно ли тебе это нужно?

Это продолжение темы начатой в статье Важны ли компилятору имена, и продолженной в Ночью все кошки серы, а using'и одинаковы, и далее в Компиляторы тоже путаются в именах. Если не читали, то лучше будет пробежаться по диагонали. Теперь вот мы подобрались к такой интересной теме, как квалифицированный и неквалифицированный поиск.

Что такое простой поиск(неквалифицированный) имени n в области S? Это механизм компилятора, который находит все объявления n, находящиеся непосредственно в этой области. Просто? С виду да, но даже этот простой механизм часто работает не так, как ожидает разработчик.

Например, у нас есть пространство имён N и локальная переменная N. Они могут сосуществовать вместе? Могут, потому что находятся в разных областях видимости. А пространство имён и глобальная переменная с тем же именем могут? Как же мы докатились до жизни такой, давайте разбираться.

Scene not Graph. Место для запятой выбирайте сами.

Scene Graph как концепция появился в академической и промышленной среде, где компьютерная графика использовалась для CAD-систем, научной визуализации и инженерного проектирования, а потом уже пришел в игры. Задачи отрисовки мира и его объектов в CAD были совсем другие и нужно было описывать, например, сложные сборки из деталей, с шестерней в редукторе, редукторе в двигателе, двигателе в машине, и такая модель отражала физическую реальность, которая играм была нужна с приставкой "не". Причины, по которым Scene Graph пришел и остается в играх довольно банальные, этой концепции учат в университете, и многие кто пришел делать игры, естественно знакомились с ней раньше других. На курсе компьютерной графики ИТМО эту модель давали уже на втором месяце и объясняли её полгода, а остальные пять или шесть техник давали всего месяц и в конце года.

Но проблема была в том, что в CAD иерархия объектов это буквальное описание устройства изделия, и перенос этой модели в игры в целом и в игровую графику в частности был концептуальной ошибкой с самого начала. Поняли это достаточно поздно, чтобы эта модель успела поселиться в мозгах целого поколения, выпуск OpenGL в 1992 году с принципиально другой моделью (immediate mode) стал первым сигналом что играм надо двигаться в другую сторону, но инерция Scene Graph в движковой архитектуре сохраняется до сих пор.

Это продолжение темы начатой в статье Важны ли компилятору имена, и продолженой в Ночью все кошки серы, а using'и одинаковы, и если вам нужна полная картина, как компилятор превращает текст в программу, то без понимания поиска имён (name lookup) дальше двигаться уже не получится.

Имена в тексте исходника это просто удобные ярлыки для людей: переменные, функции, типы. Но для компилятора имя является точкой входа в довольно сложный алгоритм, который должен однозначно определить, что именно вы имели в виду. И вот здесь начинается самое интересное: одинаково написанное имя в разных контекстах может означать совершенно разные вещи, а иногда даже не означать ничего вовсе, в зависимости от того, где и как оно используется.

C++ в этом месте особенно коварен. Язык рос десятилетиями, и правила поиска имён эволюционировали вместе с ним: добавлялись пространства имён, шаблоны, ADL, двухфазный поиск. Всё это не просто усложнило модель, оно сделало её местами неинтуитивной даже для опытных разработчиков, добавим сюда еще, что разные компиляторы исторически реализовывали эти правила (по-своему) по-разному, и часть этих различий до сих пор всплывает в коде.

Не нужно воспринимать компилятор как чёрный ящик, хотя порою поиск имён действительно выглядит как магия, но если разобрать его на отдельные шаги, то становится видно, что за этой «магией» стоит вполне строгая (хоть и исторически нагруженная) система правил. Попробую о ней рассказать.

Если говорить о производительности вне существующих решений в железе, то интуиция будет подсказывать достаточно простую модель выполнения, когда процессор обрабатывает инструкции, а память поставляет данные, и чем быстрее и то и другое, тем быстрее работает программа.

Но процессоры научились выполнять миллиарды операций в секунду, а память наращивает скорость доступа намного медленнее, и разрыв между скоростью вычислений и доступа к данным стал настолько большим, что именно ожидание памяти, превратилось в главный источник потерь производительности.

Ответом на это стало не ускорение памяти, а усложнение самих процессоров, которые перестали быть просто пассивными исполнителями кода и стали решать задачи управления потоком данных: выполнять инструкции вне порядка, переупорядочивать зависимости и на каком‑то этапе подошли к идее спекулятивно исполнять код, который, возможно, вообще не понадобится.

Предсказание ветвлений стало один из ключевых механизмов в этой системе, которая должна была снять часть времени простоя потока вычислений, но если удачное предсказание стало возможностью начать дорогие загрузки заранее и скрыть их латентность, то ошибка предсказания скрывает не только потерянные такты, но и зря использованные ресурсы памяти: шину, буферы загрузки, пропускную способность контроллера и сами кэш‑линии, которые могли бы быть заняты полезными данными.

Именно здесь возникает интересный и неочевидный компромисс, позволяющий с одной стороны, писать branchless‑код и полностью избавиться от ошибок предсказания, а с другой лишающий процессор возможности работать на опережение и запускать доступ к памяти раньше времени. Но в зависимости от того, где находятся данные в памяти выигрывать будет то один, то другой подход.

Если вы собираетесь писать branchless код, надо помнить как именно спекулятивное выполнение и предсказание ветвлений взаимодействуют с подсистемой памяти, потому что «лишняя работа» иногда ускоряет программу, а в некоторых случаях попытка сделать код более «предсказуемым» приводит к обратному эффекту.

Одной из самых сложных частей C++ до сих пор считаются правила поиска имён, и ошибки связанные с name lookup проявляются обычно уже в рантайме. Код компилится и даже работает какое-то время, но при свете луны ведёт себя не так как ожидает программист. За простыми идентификаторами скрывается многоуровневая система областей видимости, категорий имён и специальных правил, и очень многое в нашем текущем стандарте растёт прямиком из восьмидесятых, частенько без изменений. Давайте посмотрим как компилятор видит имена в C++, какие области видимости существуют и почему они ведут себя по-разному.

В C++ есть несколько типов областей видимости, вы наверное сходу назовёте глобальное пространство имён, область параметров шаблона, область видимости класса и область параметров функции, но также есть блочная область видимости и область видимости перечислений. Между этими областями есть исторически сложившаяся асимметрия, которая частенько удивляет: два объявления using, которые вводят одно и то же имя в одну и ту же область видимости внутри пространства имён компилятор съест без возражений, но если попытаться сделать то же самое других областях видимости, то получим ошибку на повторное объявление. В серии статей про "нескучное программирование" я разбираю скользкие случаи и как мы докатились до такого. Это продолжение темы, начатой в "Важны ли компилятору имена", поэтому чтобы картинка была цельной, лучше пробежать её по диагонали.

Пятничное, давно я что-то не писал про приключения ездового кота, но недавно наткнулся на  очередной пост про нейросети и искусственный интеллект, который теперь умеет диагностировать болезни, предсказывать поломки оборудования и вообще решать задачи, для которых раньше требовались годы человеческого опыта. Автор распинался про триллионы параметров, петабайты данных и революцию в промышленности, а я читал, усмехался и вспоминал, что в начале нулевых был свой “ии” для диагностики неисправностей, только работал он не на GPU-кластерах и обучался не на размеченных датасетах, а на похвале старого инженера, с которым был на дежурствах и не мешал делать выводы.

Той зимой, когда всё это случилось, я был еще студентом без диплома, но с амбициями и верил в силу образования, современных подходов, и что техника требует знаний и матерка. Дорога из славного города И. к объекту работы занимала около часа, и всё это время машина петляла между холмами со смешанным лесом, где ель выдворяет берёзы на опушку, а берёзы окружают сосны и не дают расти, а над всем этим висит то серое небо, которое зимой становится почти белым от снега, готового вот-вот посыпаться, но всё никак не решающегося.