Могут ли "неродные" указатели влиять на производительность кеша?

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

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

Но для всех, кого я знаю, это может помешать работе аппаратных префишеров. Или нет!

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

Итак, что делают современные аппаратные prefetchers? Могут ли они быть отключены "неродными" указателями?

Ответ 1

Предварительная выборка связанных структур данных (LDS) по-прежнему является известной проблемой в компьютерной архитектуре. Я не знаком с каким-либо современным процессором, который на самом деле это делает, но теоретически это возможно. За эти годы было несколько академических работ, которые предлагают некоторые варианты:

Специальный HW, который может обнаруживать значения, подобные адресам, в пределах выделенных строк кэша и выдавать предварительные выборки по этим адресам.
Метод, основанный на компиляторе, где компилятор распознает зависимости структуры данных и вставляет предварительные выборки SW или другие подсказки.

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

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

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

Некоторая библиография:

Ответ 2

Аппаратный предварительный выборщик не видит указателей, он видит адреса памяти. Не важно, откуда пришел адрес, или какой тип он имел в написанной вами программе на С++. Он просто смотрит, на какой адрес процессор запрашивается для чтения или записи.

Итак, нет, индексирование в массив не будет пугающей новой вещью, с которой CPU никогда не сталкивался раньше.