Zidentyfikuj zagrożenie związane z koherencją pamięci podręcznej, które łagodzi **std::hardware_destructive_interference_size**, oraz określ, dlaczego bezpośrednie zastosowanie **alignas** z tą wartością dla zmiennych automatycznych może mimo to nie zapobiegać degradacji wydajności między wątkami w nowoczesnych architekturach procesorowych?

Odpowiedź na pytanie.

Historia

Nowoczesne procesory stosują protokoły koherencji pamięci podręcznej, takie jak MESI, aby synchronizować dane w prywatnych pamięciach L1 różnych rdzeni. Kiedy niezależne wątki zapisują do różnych lokalizacji pamięci, które przypadkowo znajdują się na tej samej linii pamięci podręcznej (zwykle 64 lub 128 bajtów), sprzęt serializuje te operacje, ciągle unieważniając i przenosząc własność tej linii, co nazywane jest fałszywym współdzieleniem. C++17 wprowadził std::hardware_destructive_interference_size, aby ujawnić szerokość linii pamięci podręcznej architektury, pozwalając deweloperom na oddzielenie zmiennych, aby gorące zmienne każdego wątku zajmowały różne linie i unikały tego przeciążenia synchronizacji.

Problem

Zastosowanie alignas(std::hardware_destructive_interference_size) dla zmiennej o automatycznym czasie przechowywania zapewnia, że adres początkowy obiektu jest wielokrotnością rozmiaru linii pamięci podręcznej w ramach stosu konkretnego wątku. Jednakże, to wyrównanie jest lokalne dla widoku pamięci wątku i nie gwarantuje wyłącznego zajęcia fizycznej linii pamięci podręcznej. Jeśli obiekt jest mniejszy niż linia pamięci podręcznej, sąsiednie zmienne na tym samym stosie — lub zmienne na stosach różnych wątków, które przypadkowo zostały przydzielone na fizycznych adresach różniących się wielokrotnościami rozmiaru linii — mogą mapować do tej samej fizycznej linii pamięci podręcznej. W konsekwencji sprzęt nadal doświadcza ruchu koherencyjnego, gdy inny wątek zapisuje do innej zmiennej na tej samej linii, co czyni specyfikację alignas niewystarczającą dla izolacji.

Rozwiązanie

Aby zagwarantować unikanie fałszywego współdzielenia, dane muszą być uzupełnione, aby zajmowały całą linię pamięci podręcznej, zapewniając, że żadne inne dane nie dzielą tej fizycznej przestrzeni, niezależnie od układu adresów w czasie wykonywania. Osiąga się to poprzez zdefiniowanie struktury, która jest zarówno wyrównana, jak i dostosowana do std::hardware_destructive_interference_size.

#include <new>
#include <cstddef>
#include <atomic>

struct alignas(std::hardware_destructive_interference_size) PaddedCounter {
    std::atomic<int> value;
    // Wypełnienie zajmuje pozostałą część linii pamięci podręcznej, aby zapobiec dzieleniu się
    char padding[std::hardware_destructive_interference_size - sizeof(std::atomic<int>)];
};

// Tablica zapewnia, że każdy element znajduje się na innej linii pamięci podręcznej
PaddedCounter thread_counters[8];

Sytuacja z życia

Opis problemu

Procesor danych rynkowych o niskim opóźnieniu wykorzystywał osiem wątków roboczych, z których każdy utrzymywał lokalny licznik kleknięć w globalnej tablicy std::atomic<int> stats[8]. Każdy wątek inkrementował wyłącznie swój indeks bez blokad, jednak profilowanie ujawniło, że wydajność osiągnęła plateau na ułamku teoretycznego maksimum, a liczniki CPU wykazywały ponadmierne cykle koherencji pamięci podręcznej zamiast obliczeń w trybie użytkownika. Śledztwo potwierdziło, że liczby atomowe, mimo że były logicznie niezależne, były spakowane w sposób ciągły w jednej 64-bajtowej linii pamięci podręcznej, co powodowało destrukcyjne zakłócenia między rdzeniami.

Rozwiązanie 1: Lokalne wyrównane zmienne

Zespół początkowo podjął próbę zadeklarowania alignas(64) std::atomic<int> local_stat w funkcji wykonywania każdego wątku, przekazując wskaźniki do wątku monitorującego. To podejście wymagało minimalnej refaktoryzacji i unikało globalnego stanu. Okazało się jednak zawodnym, ponieważ kompilator mógł ulokować inne zmienne automatyczne obok local_stat w tej samej linii pamięci podręcznej, a różne przydziały stosu wątków mogły być oddzielone dokładnymi wielokrotnościami 64 bajtów, co powodowało, że wyrównane zmienne mapowały się na tę samą fizyczną linię i utrzymywały fałszywe współdzielenie.

Rozwiązanie 2: Alokacja na stercie z surowymi wskaźnikami

Innym rozważanym podejściem była alokacja każdego licznika za pomocą new std::atomic<int>, mając nadzieję, że alokator sterty rozproszony przydziały po odległych adresach pamięci. Choć czasami zmniejszało to kontencję, wprowadzało to niedeterministyczną wydajność, ponieważ małe alokacje często obsługiwano z ciągłych fragmentów, a metadane alokatora mogły umieścić różne obiekty na tej samej linii pamięci podręcznej. Ponadto wymagało to ręcznego zarządzania pamięcią i nie zapewniało gwarancji wyrównania lub wypełnienia w czasie kompilacji.

Wybrane rozwiązanie i wynik

Ostateczna implementacja przyjęła zdefiniowaną powyżej strukturę PaddedCounter, przechowując instancje w statycznej tablicy. To rozwiązanie zostało wybrane, ponieważ deterministycznie egzekwowało separację linii pamięci przez wypełnienie i wyrównanie w czasie kompilacji, eliminując kontencję na poziomie sprzętowym, niezależnie od układu pamięci w czasie wykonywania. Zużycie pamięci wzrosło z 32 bajtów do 512 bajtów, co było akceptowalne w przypadku zysku wydajności. Wynikiem był wzrost przezorności rozwoju o dwanaście razy i redukcja zmienności opóźnienia, spełniając wymagania przetwarzania poniżej mikrosekundy.

Co kandydaci często pomijają

Dlaczego zastosowanie alignas(std::hardware_destructive_interference_size) dla małego obiektu nie zapobiega fałszywemu współdzieleniu z innymi danymi w tym samym wątku?

alignas kontroluje tylko wyrównanie adresu początkowego obiektu, a nie jego rozciągnięcie. Jeśli obiekt jest mniejszy niż linia pamięci podręcznej (np. 4-bajtowa liczba całkowita na 64-bajtowej linii), pozostałe bajty tej linii pamięci podręcznej mogą przechowywać inne zmienne. Gdy kompilator umieści inną zmienną na tej samej linii lub gdy zmienna innego wątku mapuje się do tej fizycznej linii, występuje fałszywe współdzielenie. Prawdziwa izolacja wymaga, aby obiekt zajmował całą linię poprzez wypełnienie, a nie tylko był wyrównany do swojego początku.

Jaka jest różnica między std::hardware_destructive_interference_size a std::hardware_constructive_interference_size, i kiedy grupowanie danych w celu dopasowania do tej drugiej poprawiłoby wydajność?

std::hardware_destructive_interference_size to minimalna separacja potrzebna do unikania fałszywego współdzielenia, podczas gdy std::hardware_constructive_interference_size to maksymalny rozmiar danych, które korzystają z lokalności przestrzennej na jednej linii pamięci podręcznej. Grupowanie często używanych powiązanych pól (np. współrzędne x, y, z punktu) w strukturze, która mieści się w rozmiarze konstrukcyjnym, zapewnia, że znajdują się na tej samej linii, maksymalizując wskaźniki trafień w pamięci podręcznej i efektywność prefetching, podczas gdy rozmiar destrukcyjny stosuje się do oddzielania niepowiązanych zmiennych mutowalnych.

Jak fałszywe współdzielenie wpływa na operacje std::atomic przy użyciu memory_order_relaxed, i dlaczego relaksowane porządkowanie pamięci nie rozwiązuje degradacji wydajności?

Nawet przy memory_order_relaxed, które nie narzuca ograniczeń porządkowych na otaczające operacje pamięci, atomowy zapis nadal wymaga, aby rdzeń CPU uzyskał wyłączną własność linii pamięci podręcznej (cykl odczytu-w-łasność). Jeśli inny wątek niedawno zmodyfikował inną zmienną na tej samej linii, protokół koherencji pamięci podręcznej zmusza linię do skakania między rdzeniami. Ta synchronizacja na poziomie sprzętowym zachodzi niezależnie od logicznych gwarancji modelu pamięci C++, co oznacza, że fałszywe współdzielenie wiąże się z opóźnieniem pełnego braku trafienia w pamięć podręczną, niezależnie od określonego porządku pamięci.