Кратко и по существу — как меняются подходы компилятора и программиста при переходе от однопоточных к многопоточным приложениям, с примерами локальной оптимизации, векторизации и проблем кэш-линий.
Основная смена парадигмы
- В однопоточном коде оптимизация ориентирована на максимальную скорость одной нити: агрессивный LICM, CSE, встраивание, переупорядочивание загрузок/записей.
- В многопоточном критична масштабируемость: минимизация синхронизации, уменьшение межпоточного обмена (cache-coherence), корректность по памяти (memory model). Многие трансформации, безопасные в однопоточном контексте, запрещены или требуют оговорок (атомики, барьеры).
Локальная оптимизация (локальные преобразования)
- В однопоточном: можно свободно выносить неизменные вычисления из циклов (LICM), кэшировать результаты в регистре.
- В многопоточном: нельзя выносить или кэшировать чтение переменной, которую могут изменить другие потоки, если оно не защитено атомиком/локом. Пример: чтение флага в цикле
- Небезопасно выносить: „if (flag) …“; если другой поток меняет flag, компилятор не может предполагать «не поменяется», если доступ неконкурентный.
- Правильно: либо использовать атомик с нужной семантикой (например, атомик с acquire/release), либо локальную копию только для потокобезопасных данных.
- Практическое правило: помечайте данные как thread_local / private, используйте restrict/псевдоназвания для подсказки компилятору о неперекрывающемся доступе.
Векторизация (SIMD)
- В однопоточном: компилятор автоматически векторизует петли без зависимостей и с выровненными данными; важны выравнивание, шаг доступа и отсутствие переплетения ссылок.
- В многопоточном:
- Векторизация по-прежнему полезна внутри каждого потока — стратегия: делить работу на независимые чанки длины $C$ и внутри чанка применять SIMD ширины $W$.
- Нужно избегать векторизации, которая приводит к конкурентным записям в общую память без синхронизации (атомики SIMD обычно дорогие). Решение: использовать thread-local аккумулирование, затем редукцию.
- Пример паттерна суммы массива: пусть массив длины $N$. Разделить на $P$ потоков, каждый поток считает локальную сумму векторизированным циклом по своему диапазону, затем объединение локальных сумм:
- разбивка: диапазон на поток $k$ — элементы $\frac{kN}{P}$ .. $\frac{(k+1)N}{P}-1$
- это сохраняет векторизацию внутри потока и минимизирует межпоточный трафик.
- Векторная эффективность зависит от выравнивания: выделяйте данные с выравниванием $\text{align}=32$ или $\text{align}=64$ байт в зависимости от AVX/AVX2/AVX-512.
Кэш-строки и false sharing
- Проблема: если два потока часто модифицируют разные переменные, лежащие на одной кэш-строке, кэш-линия будет «прыгать» между ядрами (ping-pong), что сильно тормозит. Это называется false sharing.
- Размер кэш-линии: обычно $\text{CLS}=64$ байта. Частая формула числа элементов на одну линию: $\lfloor \frac{\text{CLS}}{\text{sizeof}(T)}\rfloor$.
- Примеры и решения:
- Два счётчика подряд в структуре:
- Плохо:
- struct S { int a; int b; }; // если a и b в одной линии, модификации разными потоками — false sharing
- Хорошо: выровнять/дополнить так, чтобы поля, модифицируемые разными потоками, занимали разные кэш-линии (padding до $\text{CLS}$ байт) или использовать массивы по потокам: counter[thread_id].
- Для массивов структур: распределять элементы так, чтобы частые обновления были локальны по адресу (sharding, partitioning).
- Другие приёмы: объединять мелкие обновления в батчи (batching), использовать пер-поточные буферы и отдавать их на общий ресурс реже.
Синхронизация, атомики и упорядочение памяти
- Атомики и барьеры предотвращают агрессивные оптимизации и переупорядочения компилятора/процессора: компилятор обязан не перемещать операции через атомик/барьер. Это ограничивает возможности LICM/CSE.
- Выбирайте минимально необходимую семантику памяти: например, для флага «готовности» может быть достаточно acquire/release, а не full-fence.
- Стоимость атомиков: атомарные операции на одном адресе масштабируются плохо при сильном конкурентном доступе; лучше уменьшить частоту атомиков (локальные буферы → редукция).
NUMA и привязка потоков
- В многопроцессорных системах с NUMA важно распределять память там, где будет исполняться поток (first-touch) и связывать потоки с ядрами (affinity), чтобы уменьшить межузловой трафик.
- Оптимизация: разбить данные по NUMA-нодам, запускать рабочие нити на соответствующих ядрах.
Примеры практических правил
- Разделяй и властвуй: разбить данные на независимые чанки по потокам — уменьшает синхронизацию и кэш-конфликты.
- Thread-local сначала, потом редуцируй: для редукций используйте локальные аккумуляторы, затем один слияющий шаг.
- Паддинг для переменных, часто модифицируемых разными потоками: выравнивание до $\text{CLS}$.
- Сохранять векторизацию внутри потока: организовать данные contiguously, выравнивать и строить внутренние циклы, совместимые с SIMD.
- Минимизировать атомики и частоту барьеров; использовать правильные memory_order для атомиков.
- Профилировать: измерять latency, contention, cache-miss, тепловые пики и т.д.; зачастую micro-оптимизация (например, инлайнинг) вторична по сравнению с уменьшением false sharing и contention.
Короткий пример (редукция)
- Непараллельно: суммирование массива length $N$ — возможно векторизуется автоматически.
- Эффективно параллельно:
1) Разбить на $P$ чанков по $\approx \frac{N}{P}$ элементов.
2) Каждый поток векторизовано считает локальную сумму по своему чанку.
3) Объединить $P$ локальных сумм (обычно последовательная финальная редукция или tree-reduction).
Это минимизирует межпоточный трафик и даёт и векторизацию, и масштабирование.
Итого: при переходе к многопоточности фокус смещается от «максимальной одной нити» к «минимизации синхронизации и кэш-конфликтов при сохранении локальной эффективности» — используйте разбиение данных, per-thread ресурсы, выравнивание для SIMD, padding против false sharing, и аккуратно работайте с атомиками/барьерами.