Замедление при доступе к данным на границах страницы?

Question

(Мой вопрос связан с компьютерной архитектурой и пониманием производительности. Не нашел соответствующего форума, поэтому опубликуйте его здесь как общий вопрос.)

У меня есть программа C, которая обращается к словам памяти, которыерасположены на расстоянии X байтов в виртуальном адресном пространстве.Например, for (int i=0;<some stop condition>;i+=X){array[i]=4;}.

Я измеряю время выполнения с переменным значением X.Интересно, что когда X является силой 2 и имеет размер страницы, например, X=1024,2048,4096,8192..., я получаю огромное снижение производительности.Но на всех других значениях X, таких как 1023 и 1025, замедления нет.Результаты производительности приведены на рисунке ниже.

X and Y-axis is execution time in milliseconds">

Я тестирую свою программу на нескольких персональных компьютерах, все работают под управлением Linux с x86_64 на процессоре Intel.

Что может быть причиной этого замедления?Мы попробовали буфер строк в DRAM, кэш-памяти L3 и т. Д., Которые, кажется, не имеют смысла ...

Обновление (11 июля)

Мы провели небольшой тест, добавив инструкции NOPк исходному коду.И замедление все еще там.Это Сорта Вето 4k псевдоним.Причина, связанная с отсутствием кэша конфликтов, более вероятна.

Answer 1

Здесь есть 2 вещи:

• Создание ассоциативного псевдонима кэша, создающего конфликт, пропускается, если вы только касаетесь адресов, кратных 1024 . Внутренние быстрые кэши (L1 и L2) обычно индексируются небольшим диапазоном битов из физического адреса. Таким образом, шаг в 1024 байта означает, что эти биты адреса одинаковы для всех обращений, поэтому вы используете только несколько наборов в кэше.

  Но с шагом не-степени-2 ваш доступ будет распределен по большему количеству наборов в кеше. Преимущества производительности данных размера степеней 2 * (ответ описывает это dis преимущество)

  Какой метод отображения кэша используется в процессоре Intel Core i7? - общий кэш L3 устойчив к наложению алиасов при больших смещениях степени 2, поскольку использует более сложную функцию индексации.

• Псевдоним 4k (например, в некоторых процессорах Intel). Хотя с только магазинами это, вероятно, не имеет значения. Это в основном является фактором устранения неоднозначности в памяти, когда ЦП должен быстро выяснить, может ли загрузка перезагружать недавно сохраненные данные, и он делает это на первом проходе, просто просматривая только биты со смещением страницы.

  Это, вероятно, не то, что происходит для вас, но для более подробной информации смотрите:
  Пропускная способность памяти L1: снижение эффективности на 50% при использовании адресов, которые отличаются на 4096 + 64 байта и
  Почему поэлементное сложение намного быстрее в отдельных циклах, чем в комбинированном цикле?

Любой из этих эффектов или оба эти фактора могут повлиять на Почему в 2048x2048 наблюдается огромное снижение производительности по сравнению с умножением массива 2047x2047?

---

Другим возможным фактором является то, что предварительная загрузка HW останавливается на границах физической страницы. Почему скорость memcpy () резко падает каждые 4 КБ? Но изменение шага с 1024 на 1023 не помогло бы этому в значительной степени. Предварительная выборка «следующей страницы» в IvyBridge и более поздних версиях - это только предварительная выборка TLB, а не данные со следующей страницы.

---

Я предположил x86 для большей части этого ответа, но в общем случае применяется псевдоним кэш-памяти / конфликтные пропуски. Ассоциативно-множественные кэши с простой индексацией универсально используются для кэшей L1d. (Или на старых процессорах с прямым отображением, где каждый «набор» имеет только 1 элемент). Псевдонимы 4k могут быть в основном для Intel.

Предварительная выборка за границы виртуальной страницы, вероятно, также является общей проблемой.