Инструкция по упреждающей выборке
Кажется, что общая логика для использования упреждающей выборки - то, что упреждающая выборка может быть добавлена, предоставил код, занято в обработке, пока инструкция по упреждающей выборке не завершает свою операцию. Но, кажется что, если бы слишком много инструкций по упреждающей выборке используется, то это повлияло бы на производительность системы. Я нахожу, что у нас должен сначала быть рабочий код без инструкции по упреждающей выборке. Позже мы нуждаемся к различной комбинации инструкции по упреждающей выборке в различных местоположениях кода и делаем анализ для определения участков кода, которые могли на самом деле улучшиться из-за упреждающей выборки. Там какой-либо лучший путь состоит в том, чтобы определить точные местоположения, в которых должна использоваться инструкция по упреждающей выборке?
2 ответа
В большинстве случаев инструкции предварительной выборки практически не приносят пользы, а в некоторых случаях даже могут быть контрпродуктивными. Большинство современных процессоров имеют механизм автоматической предварительной выборки, который работает достаточно хорошо, поэтому добавление программных подсказок предварительной выборки мало что дает, или даже мешает автоматической предварительной выборке, и может фактически снизить производительность.
В некоторых редких случаях, например, при потоковой передаче больших блоков данных, на которых выполняется очень мало фактической обработки, вам удастся скрыть некоторую задержку с помощью программно инициируемой предварительной выборки, но добиться этого очень сложно - вам нужно запустить предварительную выборку за несколько сотен тактов до того, как вы собираетесь использовать данные - сделайте это слишком поздно, и вы все равно получите промах в кэше, сделайте это слишком рано, и ваши данные могут быть удалены из кэша до того, как вы будете готовы их использовать. Часто при этом предварительная выборка помещается в какую-то несвязанную часть кода, что плохо для модульности и обслуживания программного обеспечения. Хуже того, если ваша архитектура меняется (новый процессор, другая тактовая частота и т.д.), так что задержка доступа к DRAM увеличивается или уменьшается, вам может понадобиться переместить инструкции предварительной выборки в другую часть кода, чтобы сохранить их эффективность.
В любом случае, если вы чувствуете, что вам действительно необходимо использовать предварительную выборку, я рекомендую использовать #ifdefs вокруг любых инструкций предварительной выборки, чтобы вы могли скомпилировать код с предварительной выборкой и без нее и посмотреть, действительно ли она помогает (или мешает) производительности, например
#ifdef USE_PREFETCH
// prefetch instruction(s)
#endif
В целом, я бы рекомендовал оставить программную предварительную выборку на втором плане, как последнюю микрооптимизацию после того, как вы сделали все более продуктивные и очевидные вещи.
Конечно, вам нужно немного поэкспериментировать, но это не значит, что вам нужно получить несколько циклов (100–300), прежде чем данные потребуются. Кэш L2 достаточно большой, чтобы предварительно загруженные данные могли оставаться там некоторое время.
Эта предварительная выборка очень эффективна перед циклом (конечно, несколько циклов), особенно если это внутренний цикл, и цикл запускается тысячи и более раз в секунду.
Также для быстрой реализации LL или реализации дерева предварительная выборка может получить ощутимое преимущество, потому что ЦП не знает, что данные потребуются в ближайшее время.
Но помните, что инструкции предварительной выборки съедают некоторую пропускную способность декодера / очереди, поэтому их чрезмерное использование снижает производительность по этой причине.