Как увеличить скорость передачи данных памяти DDR3?

Я пытаюсь измерить скорость передачи данных памяти DDR3 с помощью теста. Согласно спецификации процессора. максимальная теоретическая пропускная способность – 51,2 ГБ/с. Это должна быть объединенная пропускная способность четырех каналов, то есть 12,8 ГБ/канал. Однако это теоретический предел, и мне любопытно, как еще больше увеличить практический предел в этом посте. В описанном ниже тестовом сценарии я достиг скорости передачи данных ~14 ГБ/с, что, как я полагаю, может быть близким приближением, когда подавляется большая часть прироста пропускной способности кэшей ЦП L1, L2 и L3.

Обновление от 20 марта 2014 г. Предположение об уничтожении кешей L1–L3 неверно. Аппаратная предварительная выборка контроллера памяти будет анализировать схему доступа к данным, и, поскольку она является последовательной, у нее будет простая задача предварительной выборки данных в кэши ЦП.

Конкретные вопросы следуют внизу, но в основном меня интересует а) проверка предположений, приведших к этому результату, и б) есть ли лучший способ измерения пропускной способности памяти в .NET.

Для начала я создал тест на С# на .NET. Хотя .NET не идеален с точки зрения распределения памяти, я думаю, что это выполнимо для этого теста (пожалуйста, дайте мне знать, если вы не согласны и почему). Тест состоит в том, чтобы выделить массив int64 и заполнить его целыми числами. Этот массив должен иметь данные, выровненные в памяти. Затем я просто зацикливаю этот массив, используя столько потоков, сколько у меня есть ядер на машине, и читаю значение int64 из массива и устанавливаю его в локальное общедоступное поле в тестовом классе. Поскольку поле результата является общедоступным, мне следует избегать оптимизации компилятором вещей в цикле. Кроме того, и это может быть слабым предположением, я думаю, что результат остается в регистре и не записывается в память до тех пор, пока он не будет перезаписан снова. Между каждым чтением элемента в массиве я использую переменное смещение шага 10, 100 и 1000 в массиве, чтобы не иметь возможности получать много ссылок в одном и том же блоке кеша (64 байта).

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

Вот как я инициализирую массив данных:

_longArray = new long[Config.NbrOfCores][];
for (int threadId = 0; threadId < Config.NbrOfCores; threadId++)
{
    _longArray[threadId] = new long[Config.NmbrOfRequests];
    for (int i = 0; i < Config.NmbrOfRequests; i++)
        _longArray[threadId][i] = i;
}

А вот собственно тест:

GC.Collect();
timer.Start();
Parallel.For(0, Config.NbrOfCores, threadId =>
{
    var intArrayPerThread = _longArray[threadId];
    for (int redo = 0; redo < Config.NbrOfRedos; redo++)
        for (long i = 0; i < Config.NmbrOfRequests; i += Config.Step) 
            _result = intArrayPerThread[i];                        
});
timer.Stop();

Поскольку сводка данных очень важна для результата, я также даю эту информацию (можно пропустить, если вы мне доверяете...)

var timetakenInSec = timer.ElapsedMilliseconds / (double)1000;
long totalNbrOfRequest = Config.NmbrOfRequests / Config.Step * Config.NbrOfCores*Config.NbrOfRedos; 
var throughput_ReqPerSec = totalNbrOfRequest / timetakenInSec;
var throughput_BytesPerSec = throughput_ReqPerSec * byteSizePerRequest;
var timeTakenPerRequestInNanos = Math.Round(1e6 * timer.ElapsedMilliseconds / totalNbrOfRequest, 1);
var resultMReqPerSec = Math.Round(throughput_ReqPerSec/1e6, 1);
var resultGBPerSec = Math.Round(throughput_BytesPerSec/1073741824, 1);
var resultTimeTakenInSec = Math.Round(timetakenInSec, 1);

Пренебрегая предоставлением фактического кода вывода вывода, я получаю следующий результат:

Step   10: Throughput:   570,3 MReq/s and         34 GB/s (64B),   Timetaken/request:      1,8 ns/req, Total TimeTaken: 12624 msec, Total Requests:   7 200 000 000
Step  100: Throughput:   462,0 MReq/s and       27,5 GB/s (64B),   Timetaken/request:      2,2 ns/req, Total TimeTaken: 15586 msec, Total Requests:   7 200 000 000
Step 1000: Throughput:   236,6 MReq/s and       14,1 GB/s (64B),   Timetaken/request:      4,2 ns/req, Total TimeTaken: 30430 msec, Total Requests:   7 200 000 000

Используя 12 потоков вместо 6 (поскольку ЦП гиперпотоковый), я получаю почти такую ​​же пропускную способность (как и ожидалось): 32,9 / 30,2 / 15,5 ГБ/с.

Как видно, пропускная способность падает по мере увеличения шага, что я считаю нормальным. Отчасти, я думаю, это связано с тем, что 12 МБ кэш-памяти L3 вызывает промахи в кэш-памяти, а отчасти это может быть механизм предварительной выборки контроллеров памяти, который не работает, когда чтения так далеко друг от друга. Я также считаю, что результат шага 1000 наиболее близок к фактической практической скорости памяти, поскольку он должен убить большую часть кешей ЦП и «надеюсь» убить механизм предварительной выборки. Более того, я предполагаю, что большая часть накладных расходов в этом цикле связана с операцией выборки памяти, а не с чем-то еще.

Оборудование для этого теста: Intel Core I7-3930 (спецификации: Краткое описание процессора, более подробная и действительно подробная спецификация ), используя в общей сложности 32 ГБ памяти DDR3-1600.

Открытые вопросы

1. Правильно ли я делаю предположения, сделанные выше?

2. Есть ли способ увеличить использование пропускной способности памяти? Например, сделать это на C/C++ вместо этого и распределить выделение памяти в куче, чтобы можно было использовать все четыре канала памяти.

3. Есть ли лучший способ измерения передачи данных в память?

Премного благодарен за вклад в это. Я знаю, что это сложная область под капотом...

Весь приведенный здесь код доступен для загрузки по адресу https://github.com/Toby999/ThroughputTest. Не стесняйтесь обращаться ко мне по электронной почте для переадресации tobytemporary[at]gmail.com.