Действительно ли возможно заблокировать некоторые данные в кэше ЦП?

Not intentionally, no. Among other things, you have no idea how big the cache is, so you have no idea of what's going to fit. Furthermore, if the app were allowed to lock off part of the cache, the effects on the OS might be devastating to overall system performance. This falls squarely onto my list of "you can't do it because you shouldn't do it. Ever."

What you can do is to improve your locality of reference - try to arrange the loop such that you don't access the elements more than once, and try to access them in order in memory.

Without more clues about your application, I don't think more specific advice can be given.

CPU обычно не предлагает детального управления кешем, вам не разрешено выбирать, что удаляется, или закреплять что-то в кеше. У вас есть несколько операций с кешем на некоторых процессорах. Так же немного информации о том, что вы можете сделать: Вот несколько интересных инструкций, связанных с кешем на новых процессорах x86 {-64} (Подобные вещи превращают переносимость в ад, но я подумал, что вам может быть любопытно)

Software Data Prefecth

Вневременная инструкция prefetchnta, который извлекает данные в кэш второго уровня, минимизация загрязнения кэша.

Временные инструкции выглядят так следует:

 * prefetcht0 - извлекает данные во все уровни кеша, то есть в

кэш второго уровня для процессора Pentium® 4.

 * prefetcht1 - идентичен prefetcht0

* prefetcht2 - идентично prefetcht0

Кроме того, имеется набор инструкций для доступа к данным в памяти, но явно указывающий процессору не вставлять данные в кэш. Это так называемые вневременные инструкции. Пример одного из них находится здесь: MOVNTI .

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

Unless your code does something completely different in between writing to the array, then most of the array will probably be kept in the cache.

Unfortunately there isn't anything you can do to affect what is in the cache, apart from rewriting your algorithm with the cache in mind. Try to use as little memory as possible in between writing to the memory: don't use lot's of variables, don't call many other functions, and try to write to the same region of the array consecutively.

У меня проблема .... Я записываю данные в массив в цикле while. Дело в том, что я делаю это очень часто. Похоже, что это письмо стало узким местом в коде. Как я полагаю, это вызвано записью в память. Этот массив не очень большой (примерно 300 элементов). Вопрос в том, можно ли это сделать таким образом: сохранить в кеше и обновить в памяти только после завершения цикла while?

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

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

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

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

И, наконец, два очевидных инструменты, которые следует использовать вместо того, чтобы гадать о поведении кеша:

• Профилировщик и cachegrind, если он доступен. Хороший профилировщик может предоставить вам много статистических данных о промахах кеша, и cachegrind также предоставит вам много информации.
• Мы здесь, в StackOverflow. Если вы разместите свой код цикла и спросите, как можно улучшить его производительность, я Я уверен, что многим из нас это будет интересно.

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

В этом случае array2 будет вполне " hot "и оставаться в кеше только по этой причине. Хитрость заключается в том, чтобы не допустить array1 из кеша (!). Вы читаете его только один раз, поэтому кешировать его нет смысла. Инструкция SSE для этого - MOVNTPD , внутренний void_mm_stream_pd (double * destination, __m128i source)

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

Even if you could, it's a bad idea.

Modern desktop computers use multiple-core CPUs. Intel's chips are the most common chips in Desktop machines... but the Core and Core 2 processors don't share an on-die cache.

That is, didn't share a cache until the Core 2 i7 chips were released, which share an on-die 8MB L3 cache.

So, if you were able to lock data in the cache on the computer I'm typing this from, you can't even guarantee this process will be scheduled on the same core, so that cache lock may be totally useless.

Если запись выполняется медленно, убедитесь, что никакое другое ядро ​​ЦП не записывает в ту же область памяти одновременно.

Если у вас проблемы с производительностью, ничего не предполагайте, сначала измерьте. Например, закомментируйте записи и посмотрите, отличается ли производительность.

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

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

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

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