Ложный обмен

В информатике . ложное совместное использование — это модель использования, снижающая производительность, которая может возникнуть в системах с распределенными, когерентными кэшами размером с наименьший блок ресурсов, управляемый механизмом кэширования Когда участник системы пытается периодически получить доступ к данным, которые не изменяются другой стороной, но эти данные используют общий блок кэша с изменяемыми данными , протокол кэширования может заставить первого участника перезагрузить весь блок кэша, несмотря на отсутствие логическая необходимость. Система кэширования не знает о деятельности внутри этого блока и заставляет первого участника нести накладные расходы системы кэширования, необходимые для истинного совместного доступа к ресурсу.

Кеши многопроцессорных процессоров

Безусловно, наиболее распространенное использование этого термина - в современных кэшах многопроцессорных ЦП , где память кэшируется в строках небольшой степени размером в два слова (например, 64 выровненных , смежных байта ). Если два процессора работают с независимыми данными в одной и той же области адреса памяти , которые хранятся в одной строке, механизмы когерентности кэша в системе могут заставить всю строку проходить через шину или системы. соединяться при каждой записи данных, вызывая остановку памяти в дополнение к потере пропускной способности . В некоторых случаях устранение ложного совместного использования может привести к повышению производительности на порядок. Ложное совместное использование является неотъемлемым артефактом протоколов автоматической синхронизации кэша и может также существовать в таких средах, как распределенные файловые системы или базы данных, но в настоящее время его распространенность ограничивается кэшами ОЗУ.

Пример

#include <iostream>
#include <thread>
#include <new>
#include <atomic>
#include <chrono>
#include <latch>
#include <vector>

using namespace std;
using namespace chrono;

#if defined(__cpp_lib_hardware_interference_size)
// default cacheline size from runtime
constexpr size_t CL_SIZE = hardware_constructive_interference_size;
#else
// most common cacheline size otherwise
constexpr size_t CL_SIZE = 64;
#endif

int main()
{
    vector<jthread> threads;
    int hc = jthread::hardware_concurrency();
    hc = hc <= CL_SIZE ? hc : CL_SIZE;
    for( int nThreads = 1; nThreads <= hc; ++nThreads )
    {
        // synchronize beginning of threads coarse on kernel level
        latch coarseSync( nThreads );
        // fine synch via atomic in userspace
        atomic_uint fineSync( nThreads );
        // as much chars as would fit into a cacheline
        struct alignas(CL_SIZE) { char shareds[CL_SIZE]; } cacheLine;
        // sum of all threads execution times
        atomic_int64_t nsSum( 0 );
        for( int t = 0; t != nThreads; ++t )
            threads.emplace_back(
                [&]( char volatile &c )
                {
                    coarseSync.arrive_and_wait(); // synch beginning of thread execution on kernel-level
                    if( fineSync.fetch_sub( 1, memory_order::relaxed ) != 1 ) // fine-synch on user-level
                        while( fineSync.load( memory_order::relaxed ) );
                    auto start = high_resolution_clock::now();
                    for( size_t r = 10'000'000; r--; )
                        c = c + 1;
                    nsSum += duration_cast<nanoseconds>( high_resolution_clock::now() - start ).count();
                }, ref( cacheLine.shareds[t] ) );
        threads.resize( 0 ); // join all threads
        cout << nThreads << ": " << (int)(nsSum / (1.0e7 * nThreads) + 0.5) << endl;
    }
}

Этот код показывает эффект ложного совместного использования. Он создает увеличивающееся количество потоков от одного потока до количества физических потоков в системе. Каждый поток последовательно увеличивает один байт строки кэша, которая в целом распределяется между всеми потоками. Чем выше уровень конкуренции между потоками, тем больше времени занимает каждое приращение. Вот результаты для системы Zen4 с 16 ядрами и 32 потоками:

1: 1
2: 4
3: 6
4: 9
5: 11
6: 13
7: 15
8: 17
9: 16
10: 18
11: 21
12: 25
13: 29
14: 35
15: 39
16: 41
17: 43
18: 44
19: 48
20: 49
21: 51
22: 53
23: 58
24: 61
25: 68
26: 75
27: 79
28: 82
29: 85
30: 88
31: 91
32: 94

Как видите, в рассматриваемой системе выполнение операции увеличения строки общего кэша может занять до 100 наносекунд, что соответствует примерно 100 наносекундам. 420 тактов на этом процессоре.

Смягчение

Существуют способы смягчить последствия ложного обмена. Например, ложное совместное использование кэшей ЦП можно предотвратить путем изменения порядка переменных или добавления заполнения (неиспользуемых байтов) между переменными. Однако некоторые из этих изменений в программе могут увеличить размер объектов, что приведет к более интенсивному использованию памяти. Преобразования данных во время компиляции также могут уменьшить ложное совместное использование. Однако некоторые из этих преобразований не всегда могут быть разрешены. Например, проект стандарта языка программирования C++ C++23 требует, чтобы члены данных располагались так, чтобы последующие члены имели более высокие адреса.

Существуют инструменты для обнаружения ложного обмена. Существуют также системы, которые обнаруживают и устраняют ложное разделение при выполнении программ. Однако эти системы несут некоторые накладные расходы на выполнение.

Внешние ссылки

• Легкое понимание ложного обмена
• Блог C++ Today: False Sharing снова в моде!
• Статья доктора Доббса: Устранение ложного обмена информацией
• Будьте осторожны при попытке устранить ложное совместное использование в Java.