Помните, что LLC-load учитывает только те нагрузки, которые пропустили в L1d и L2. Как доля от общей загрузки (L1-dcache-loads), это, вероятно, очень хорошая частота попаданий для всей иерархии кэша (благодаря хорошей локализации и / или успешной предварительной выборке.)
( Ваш ЦП имеет 3-уровневый кэш , поэтому последний уровень - это общий L3; L1 и L2 - частные кэш-память для каждого ядра. На ЦП с 2 уровнями кэша LLC будет L2.)
Только 9 000 обращений, которые должны были пройти до DRAM за 10 секунд, очень и очень хорошо.
Низкий коэффициент попадания LLC с таким низким суммарным LLC-нагрузками говорит о том, что ваша рабочая нагрузка имеет хорошую локализацию для большинства своих обращений, но пропускаемые доступы часто должны доходить до DRAM, и только половина им выгодно иметь кэш L3 вообще.
related: Кэш-дружественное офлайн случайное чтение , и посмотрите ответ @ BeeOnRope на Понимание детализации при сравнении двух разных реализаций алгоритма BFS , где он говорит абсолютное число ООО пропускает то, что имеет значение для производительности.
Алгоритм с плохой локальностью будет генерировать лот пропусков L2 и часто много попаданий L3 (вполне возможно, с высокой частотой попаданий L3), но также и много полных пропусков L3, так что конвейер большую часть времени ждет память.
Какой показатель вы могли бы предложить, чтобы измерить, как моя программа работает с точки зрения нагрузки на память?
Хотите знать, сколько общего объема памяти вызывает ваша программа, включая предварительные выборки? то есть, какое влияние это может оказать на другие программы, конкурирующие за пропускную способность памяти? offcore_requests.all_requests может сказать вам, сколько запросов (включая предварительные выборки L2, обходы страниц и обе загрузки и сохранения, но не предварительные выборки L3) проходят через L2 в общий кэш L3, независимо от того, выполняются ли они в общем L3 или нет. ( Используйте ocperf.py обертку для perf. У моего Скайлэйка есть это событие; IDK, если ваш Нехалем будет.)
Для определения того, является ли ваш код узким местом в памяти, разумно было бы LLC-load-misses в секунду в качестве абсолютной меры. Skylake, по крайней мере, имеет cycle_activity.stalls_l3_miss для подсчета циклов, в которых не было выполнено ни одного мопа, и была выдающаяся мисс L3. Если это больше, чем пара% от общего количества циклов, вам следует избегать этих остановок.
(Я сам не пробовал использовать эти события для изучения чего-либо, возможно, это не самое полезное предложение. Трудно найти правильный вопрос, который нужно задать себе при профилировании; есть много событий, на которые вы можете посмотреть, но используя им научиться чему-то, что поможет вам понять, как изменить ваш код, сложно. Это очень помогает иметь хорошее представление о том, как ваш код использует память, так что вы знаете, что искать. Для такого общего вопроса сложно много говорить.)
Можно ли предложить способ разбить файл эталонного теста, чтобы увидеть, какие циклы вызывают наибольшее напряжение?
Вы можете использовать perf record -e whatever / perf report -Mintel, чтобы выполнить статистическое профилирование на основе выборки для любого события, которое вы хотите, чтобы увидеть, где находятся горячие точки.
Но за ошибки в кеше иногда вина заключается в некотором коде, который зацикливается на массиве и удаляет много ценных данных, а не в коде, касающемся ценных данных, которые все еще были бы горячими.
Зацикливание большого массива может не привести к пропаданию многих кэшей, если аппаратная предварительная выборка выполнит свою работу.
linux perf: как интерпретировать и находить горячие точки . очень может быть полезно использовать выборку из стека, если вы точно не знаете, что в вашей программе медленное и быстрое. Выборка стека вызовов для каждого события покажет вам, какой вызов функции находится высоко в дереве вызовов, и виноват во всей работе, которую выполняют вызываемые абоненты. Во-первых, избежать этого вызова гораздо лучше, чем немного ускорить вызываемые им функции.
(Избегайте работы вместо того, чтобы выполнять ту же самую работу с лучшей грубой силой. Тщательное применение максимальной грубой силы, которую современный ЦП может использовать для AVX2, полезно после после того, как вы установили, что выне могу не делать этого в первую очередь.)