Производительность кэша довольно сложна, и действительно надежные ответы придут от разработчиков оборудования или разработчиков операционных систем, которые специально работают с планированием диспетчеризации. Раньше я работал с инструментами анализа производительности в больших системах IBM, поэтому могу дать частичный, слегка устаревший ответ:
Во-первых, кеш-память является ассоциативной по адресу. Если часть памяти адресована, «строка кэша» для этого адреса загружается в кэш. В зависимости от конструкции процессора длина может составлять 4, 8, 16 или 32 байта. (Может быть, больше.) Это, скорее всего, будет основано на "сглаживании" аппаратных адресов; другими словами, 32-байтовая строка будет на границе, которая выравнивается с адресом, кратным 32. Ссылка на память может находиться в начале, середине или конце этой строки кэша.
Как только он находится в кеше, адрес используется как «поиск» для поиска кэшированных данных.
Справочная информация поможет вам, если строка кэша достаточно велика, чтобы ссылаться на «соседний» элемент, который, как оказалось, был кэширован как часть строки кэша. Прыжки через ваш массив победят это.
Дизайн кэша сильно различается в зависимости от поставщика, линейки продуктов, цены процессора и многого другого. Идеальная оптимизация кэша будет очень труднодостижимой, если (1) вы не знаете много о машине, на которой собираетесь работать, и (2) вы действительно не заинтересованы в работе на любой другой машине.
Еще один фактор, который следует учитывать, заключается в том, что 32-разрядные адреса в два раза меньше 64-разрядных адресов, и это существенно влияет на объем кэшируемых данных. Предоставление большего количества бит адресам означает меньшее количество бит для данных, более или менее.
Предварительная выборка - это скорее колдовство, чем наука. Извлечение памяти из данных в кеш стоит дорого, даже если она асинхронна от выполнения процессора (хотя она никогда не может быть слишком отделена от выполнения). Локальная ссылка - хорошее правило, хотя оно будет основано на аппаратной архитектуре таким образом, что это не обязательно соответствует выполнению кода в микроуровне. LRU (используется в последнее время) - это распространенный метод определения того, что загружать из кэша, но удаление чего-либо из кэша, чтобы освободить место для чего-то, что в итоге не используется никогда, не является такой хорошей оптимизацией. Поэтому предварительная выборка будет, по меньшей мере, разумной.
РЕДАКТИРОВАТЬ: проблемы с виртуальной памятью, переключение задач и т. Д.
Виртуальная память, безусловно, делает вещи намного интереснее, особенно в операционных системах, которые поддерживают несколько адресных пространств. Кэширование, скорее всего, будет основано на реальных адресах, а не на виртуальных, поэтому такие вещи, как перестановка страниц, могут иметь интересные побочные эффекты при кэшировании. Как правило, страница, которая должна быть выгружена или освобождена, сначала будет признана недействительной и перемещена в «список очистки» (где ее можно записать в файл подкачки) или в «свободный список». В зависимости от реализации, эти страницы все еще могут быть восстановлены приложением, но они больше не адресуемы - это означает, что в процессе их восстановления возникнет сбой страницы. Поэтому, как только страница была удалена из рабочего набора приложения, очень вероятно, что любые строки кэша, связанные с ней, будут признаны недействительными. Если страница интенсивно не используется, то она также вряд ли будет иметь большой объем в кеше, но в ситуации интенсивной перестановки производительность кэша может сильно пострадать наряду с перестановкой.
Кроме того, некоторые конструкции кэша имеют «общий» кэш, и большинство или все имеют кэш-память, относящуюся к процессору и ядру. Если кэш назначен определенному процессору или ядру и это ядро меняет задачу, весь кэш, вероятно, будет очищен во избежание повреждения новым процессом. Это не включает переключение потоков, поскольку потоки выполняются в одном и том же процессе и в одном и том же адресном пространстве. Настоящая проблема здесь заключается в том, что высокая активность в других приложениях в системе может повлиять на производительность вашего кэша. Общий кэш в некоторой степени облегчает эту проблему, но его необходимо более тщательно контролировать, чтобы избежать повреждений.