Уменьшение промахов в кеше за счет хорошего дизайна

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

Такой вид оптимизации зависит от аппаратной архитектуры, поэтому лучше использовать профилировщик для конкретной платформы, например Intel VTune, для обнаружения возможных проблем с кешем.

Для операций с привязкой к данным

1. использовать массивы и векторы вместо списков, карт и наборов

2. обрабатывать по строкам по столбцам

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

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

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

Немного устарел, но в «Черной книге по программированию графики» Майка Абраша все еще есть много хороших общих советов.

Вот некоторые вещи, которые мне нравится учитывать при работе с таким кодом.

• Подумайте, хотите ли вы «структуры массивов» или «массивы структур». То, что вы хотите использовать, будет зависеть от каждой части данных.
• Старайтесь, чтобы структуры были кратными 32 байтам, чтобы они равномерно упаковывали строки кэша.
• Разделите данные на «горячие» и «холодные» элементы. Если у вас есть массив объектов класса o, и вы часто используете ox, oy, oz вместе, но только изредка нуждаетесь в доступе к oi, oj, ok, тогда подумайте о том, чтобы сложить ox, oy и oz вместе и переместить i, j и k частей в параллельную подмышечную структуру данных.
• Если у вас есть многомерные массивы данных, то при обычном порядке расположения строк доступ будет очень быстрым при сканировании по предпочтительному измерению и очень медленным по другим. Сопоставление его с заполнениеизгиб вместо этого поможет сбалансировать скорости доступа при перемещении в любом измерении. (Техники блокировки аналогичны - они просто Z-порядок с большим основанием.)
• Если вы должны столкнуться с ошибкой кеширования, постарайтесь как можно больше использовать эти данные, чтобы амортизировать стоимость.
• Вы делаете что-нибудь многопоточное? Остерегайтесь замедления из-за протоколов согласованности кеша. Заполните флаги и маленькие счетчики, чтобы они находились в отдельных строках кэша.
• SSE на Intel предоставляет некоторые встроенные функции предварительной выборки, если вы заранее знаете, к чему будете получать доступ.

Также, если вы используете C++ и многопоточность, вам необходимо учитывать ложное совместное использование, локальность и горячие данные в кеше каждого процессора. Это может иметь большое значение. Также, особенно в многопоточных вычислениях, методы LIFO более эффективны, чем вычисления в режиме FIFO, но они также действительны в однопроцессорной архитектуре.