Cache-conscious размещение данных в Rust: зонирование полей, false sharing и правило 128 байт

Автор блога (ник eigenBasis на Hacker News) продолжает серию «Низкоуровневый системный дизайн в Rust» постом о размещении данных в памяти многопоточных структур. Отправная точка, SPSC-кольцевой буфер (single-producer/single-consumer ring buffer): один поток-производитель дописывает элементы, один поток-потребитель их вычитывает, координируясь через два счётчика, tail (куда пишет производитель) и head (откуда читает потребитель).

Центральная проблема, false sharing («ложное разделение»): если два ядра процессора пишут в разные поля структуры, которые случайно попали в одну 64-байтную кэш-линию (стандартный размер линии на x86-64 и большинстве AArch64), аппаратный протокол когерентности кэша начинает незаметно сериализовать их работу, ядра фактически блокируют друг друга, хотя формально работают с разными переменными. Из-за этого код выглядит lock-free (без явных блокировок), но замеры производительности показывают обратное, а профилировщики не указывают на одну конкретную «горячую» строку, проблема размазана по архитектуре данных.

Решение автор называет «зонированием полей» (field zoning): поля группируются по тому, какое ядро их пишет и как часто. В примере с кольцевым буфером выделены зоны: producer-hot (tail, счётчик производителя, и cached_head, локальный снимок последнего известного значения head, который производитель хранит сам, чтобы не читать чужую память лишний раз), consumer-hot (head и симметричный cached_tail), и cold (closed, metrics, config, buffer), редко используемые поля, которые нарочно не выравниваются и могут делить одну кэш-линию, поскольку экономия памяти здесь важнее скорости доступа.

Чтобы порядок полей в структуре не «расползся» (по умолчанию Rust, режим repr(Rust), не гарантирует порядок полей, компилятор волен переставлять их для минимизации отступов), структуру нужно объявлять с атрибутом #[repr(C)], который фиксирует порядок полей ровно таким, каким его написал разработчик. Важный нюанс: repr(C) на внешней структуре не распространяется рекурсивно на вложенные структуры, если у Metrics или Config есть свой значимый порядок полей, им нужен собственный repr(C).

Механизм, который реально разносит поля по разным кэш-линиям, обёртка CacheAligned: структура с атрибутом #[repr(C, align(128))], выравнивающая значение по границе в 128 байт. Здесь и заключается контринтуитивный момент поста: почему выравнивание идёт по 128 байт, если кэш-линия, 64? Ответ, некоторые процессоры выполняют адаптивную предвыборку соседних линий (adjacent-line / spatial prefetch): тронув одну 64-байтную линию, ядро может заодно подтянуть в кэш и соседнюю. Если «горячие» данные производителя и потребителя физически соседствуют, такая предвыборка на аппаратном уровне провоцирует false sharing, даже когда поля формально лежат в разных линиях, автор называет это «false sharing, вызванным предвыборщиком». Выравнивание по 128 байт гарантирует, что каждое горячее поле начинается на чётной границе 64-байтной линии, и предвыборка соседней линии тянет за собой пустой отступ, а не чужие данные.

Автор подчёркивает, что конкретное число (64, 128 и т.д.), не универсальная константа, а специфичная для платформы политика, и приводит реальные значения из библиотеки Crossbeam (тип CachePadded): 128 байт на x86-64, AArch64 и powerpc64; 256 байт на s390x; 32 байта на arm, mips, mips64, sparc и hexagon; 16 байт на m68k; 64 байта на остальных архитектурах. При этом сам Crossbeam оговаривает, что это обоснованные предположения, а не гарантия того, что они совпадают с физическим размером линии конкретного процессора, вывод: доверять любому единственному числу нельзя, нужно проверять бенчмарками на целевом железе.

Отдельно автор разбирает контринтуитивный вывод: интуитивное желание «помочь» аппаратному предвыборщику, вручную вставив в горячий цикл инструкции предвыборки (mm_prefetch или core::intrinsics::prefetch* в Rust), на SPSC-кольцевом буфере может, наоборот, ухудшить производительность, рассуждение на этот счёт в тексте обрывается на полуслове (материал продолжается в следующих частях серии).

Ключевые факты

Часть 1 серии «Низкоуровневый системный дизайн в Rust»: как размещать в памяти поля структуры, с которой работают несколько ядер процессора одновременно, на примере SPSC-кольцевого буфера.
False sharing, когда поля, которые пишут разные ядра, случайно попадают в одну 64-байтную кэш-линию: аппаратная когерентность кэша незаметно сериализует ядра, код выглядит lock-free, а замеры производительности показывают деградацию.
Решение, «зонирование полей» (field zoning): группировка полей по владельцу записи и частоте обращения (producer-hot / consumer-hot / cold); #[repr(C)] обязателен, чтобы Rust не переставил поля местами.
Обёртка CacheAligned с #[repr(C, align(128))] физически разносит горячие поля по разным кэш-линиям; выравнивание берут по 128, а не 64 байта, из-за адаптивной предвыборки соседних линий на некоторых CPU.
Точное число выравнивания, платформенно-специфичная политика, а не константа: Crossbeam использует 128 байт на x86-64/AArch64/powerpc64, 256 на s390x, 32 на arm/mips/sparc/hexagon, 16 на m68k, 64 на остальных, проверять нужно бенчмарками, а не доверять одному числу.

Почему это важно

Пост показывает конкретный, воспроизводимый источник деградации производительности в многопоточном коде на Rust (и в целом на любом языке с ручным управлением памятью), который не ловится обычным профилированием: false sharing через кэш-когерентность. Код формально корректен и «безлоковый», но два ядра, пишущие в физически соседние поля, аппаратно блокируют друг друга, и единственный способ это увидеть, понимать раскладку структуры в памяти, а не только логику алгоритма.

Кому это важно

Материал адресован разработчикам высокопроизводительных многопоточных систем на Rust, авторам очередей, кольцевых буферов, лок-фри структур данных, всего, что работает на границе нескольких ядер в горячем пути (высокочастотная торговля, сетевые стеки, брокеры сообщений, любые SPSC/MPSC-примитивы).

Как это применить

Практический рецепт из поста: (1) для каждого поля структуры определить, какое ядро его пишет и как часто, разложить на producer-hot/consumer-hot/cold зоны; (2) обязательно указывать #[repr(C)] на структуре, иначе компилятор Rust волен переставить поля местами и разрушить зонирование; (3) оборачивать горячие поля в тип наподобие CacheAligned с #[repr(C, align(128))], чтобы физически развести их по кэш-линиям; (4) не выравнивать холодные поля, экономия памяти там важнее; (5) не доверять слепо числу 128 или 64, сверять с реальной архитектурой (пример, таблица Crossbeam по платформам) и подтверждать бенчмарками на целевом железе.

Можно ли доверять

Это техническая инженерная статья (не рекламный или маркетинговый материал), которая опирается на проверяемые факты: официальную документацию Rust Reference о гарантиях repr(Rust) против repr(C), и реальные значения из опубликованного кода библиотеки Crossbeam (тип CachePadded) по разным архитектурам. Пост, часть продолжающейся образовательной серии с собственным примером кода (кольцевой буфер), обсуждался на Hacker News со скромным откликом (16 баллов, 7 комментариев на момент сбора), типичная реакция на нишевый, но качественный технический контент, а не вирусная новость.

Риски и подводные камни

Слепое копирование магического числа выравнивания (128 или 64) без замера на реальном целевом процессоре, сам Crossbeam оговаривает, что его таблица платформ, обоснованное предположение, а не гарантия совпадения с физическим размером кэш-линии конкретного чипа. Ещё одна ловушка: #[repr(C)] на внешней структуре НЕ фиксирует рекурсивно порядок полей во вложенных структурах, если внутри Metrics или Config есть значимый для производительности порядок, им нужен собственный repr(C). Чрезмерное выравнивание холодных полей бессмысленно тратит память. А ручные подсказки предвыборки (prefetch-хинты), вставленные из лучших побуждений в горячий цикл, могут на практике снижать, а не повышать производительность, контринтуитивный момент, который автор обещает раскрыть подробнее далее по тексту.

«Код выглядит lock-free. Бенчмарк говорит обратное.»

— eigenBasis, автор поста