Может «не родной» указатели повреждают производительность кэша?
Насколько я могу судить, аппаратные средства предварительной выборки будут по крайней мере обнаруживать и извлекать постоянные шаги в памяти. Дополнительно это может контролировать шаблоны доступа к данным, что бы это ни значило на самом деле. Что заставило меня задуматься, аппаратные средства предварительной выборки когда-либо основывают свои решения на фактических данных, хранящихся в памяти, или исключительно на поведении, которое демонстрирует программа?
Причина, по которой я спрашиваю, заключается в том, что я буду иногда использовать «не родные» указатели в качестве указателей. Простым примером этого может быть предварительно выделенный массив вещей и маленькие целые числа, индексирующие этот массив вместо указателей. Если мне нужно хранить много таких «указателей», экономия памяти может быстро возрасти и, в свою очередь, косвенно улучшит производительность кэша за счет использования меньшего количества памяти.
Но, насколько я знаю, это может помешать работе аппаратных средств предварительной выборки. Или нет!
Я, конечно, могу себе представить, реалистично или нет, модуль предварительной выборки, который проверяет строки кэша, который входит в кэш L1 для адресов собственных указателей и начинает извлекать их в L2 или что-то подобное. В этом случае мой умный прием сохранения памяти внезапно кажется менее решительным.
Итак, что же делают современные аппаратные устройства предварительной выборки? Могут ли они быть сбиты «неродными» указателями?
Решение
Предварительная выборка связанных структур данных (LDS) остается известной проблемой в компьютерной архитектуре. Я не знаком ни с одним современным процессором, который действительно это делает, но теоретически это возможно. За эти годы было сделано несколько научных работ, в которых предлагается несколько вариантов:
- Выделенный HW, который может обнаруживать адресоподобные значения в извлеченных строках кэша и выдавать предварительные выборки по этим адресам.
- Метод с помощью компилятора, при котором компилятор распознает зависимости структуры данных и вставляет предварительные выборки SW или другие подсказки.
Оба эти метода могут быть затронуты вашей техникой (первый может оказаться бесполезным, второй может работать, если компилятор достаточно умен).
Конечно, вам действительно нужно работать на такой машине, так что это только теоретически, и вам не нужно менять свою практику, если она хорошо работает для вас, но это показывает, что профилирование должно быть специфичным для каждой микроархитектуры и Система, и что помогает вам в одном случае, может быть менее эффективным в другом.
Вообще говоря — не просто доверяйте процессору выполнять или не выполнять некоторую оптимизацию (если она не задокументирована), всегда проверяйте, что вы получаете ожидаемое поведение.
Кстати, обратите внимание, что даже если HW видит содержимое памяти, оно все еще находится в виртуальном адресном пространстве — HW в любом случае придется выполнить какой-то перевод на физический адрес, чтобы использовать его, так что в некотором смысле это не так. не должно быть никаких дополнительных накладных расходов.
Немного библиографии:
Другие решения
Аппаратный prefetcher не видит указатели, он видит адреса памяти. Неважно, откуда пришел адрес или какой он был в написанной вами C ++ программе. Он просто смотрит по тому адресу, с которого ЦПУ велят читать или писать.
Так что нет, индексирование в массив не будет страшной новой вещью, с которой ЦП никогда не сталкивался раньше.