Senior C++ — Вопросы на собеседовании C++

Как промахи кэша влияют на раскладку данных?

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

Когда оправдан lock-free и чем он отличается от wait-free?

Lock-free гарантирует, что прогресс делает хоть какой-то поток; wait-free — что каждый поток завершит операцию за ограниченное число шагов. Lock-free оправдан при реальной конкуренции на небольшой, хорошо понятой структуре — очередь, счётчик, — где мьютекс измеримо доминирует. Как выбор по умолчанию он не оправдан: такой код трудно написать верно и трудно тестировать, а неконкурентный мьютекс быстр, поэтому честный ответ начинается с измерения.

Объясните упорядочивание памяти в `std::atomic`.

seq_cst стоит по умолчанию и даёт единый общий порядок для всех потоков — корректно и проще всего для рассуждений. Пара acquire/release устанавливает happens-before между освобождающей записью и захватывающим чтением: именно это внутри делает мьютекс, и этого достаточно для большинства схем производитель-потребитель. relaxed гарантирует только атомарность без порядка и уместен для чего-то вроде счётчика статистики. Ослабление порядка — измеренная оптимизация, а не точка старта.

Проект собирается двадцать минут. С чего начать?

Сначала измерить: какие единицы трансляции и какие заголовки доминируют. Затем резать граф включений — предварительные объявления вместо include, PIMPL на широко включаемых классах, вынос шаблонов оттуда, где стоимость инстанцирования реальна. Дальше механические выигрыши: предкомпилированные заголовки, ccache, параллелизм, unity-сборки и линкер вроде lld или mold. Модули решают это по-настоящему там, где тулчейн к ним готов.

Код работает медленнее, чем должен. Какой у вас метод?

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