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++ помиляється достатньо часто, щоб бути небезпечною. Профілювати, щоб знайти, куди справді йде час, і дивитися на алгоритм раніше за мікрооптимізації. Перевіряти, що зробив оптимізатор, а не припускати: згенерований код відповідає на питання, на які читання джерела відповісти не може. І контролювати середовище — прапорці збірки, прогріті кеші, стрибки частоти й шум від інших процесів інакше дадуть цифри, яких немає.