Время доступа к памяти

[Pavia]

Pavia вытесняющая многозадачность не причем, если запись/вычисление длится 20мкс (запись ~300000 байтов) то тут некуда вклиниваться.

Сохранение контекста занимает около 1 мкс. Может прилететь прерывании, но они не частые от 100 до 50 000.
За 3-5 мкс может произойти многое о чем мы не знаем. Но такие события не частые поэтому заботиться о них не стоит.

многозадачность влияние на механизм кэширования, здесь интереснее.

Я уже писал. Однозначно влияет, при смене контекста происходит сброс кэша.

и вытесняется код приложения, или же область памяти, куда происходит запись?

Не-то не сё сбрасывается TLB. А вот на что влияет затрудняюсь с ответом думаю и накод и на данные.

Вопервых не понятно о каком кеше идет речь? Речь о кеш памяти ЦП, или в ОЗУ тоже есть нечто такое? Во вторых, если о ЦП, кешируется и вытесняется код приложения, или же область памяти, куда происходит запись?

О кэше ЦП. ОЗУ - это DRAM она периодически обновляется, но там задержка на обновление около 10% это не разы * (Не уверен).

. Но разницы в десятки раз тут никак не может быть.

Померил задержку своего ноутбука latence:
RAM - 80 нс
L3 - 61 нс
L2 - 7.9 нс
L1 - 1.8 нс
Разница в 44 раза! Если что интел приводит цифры примерно такие же.

[CRobin]

Pavia если так, тогда напрашиваются следующие выводы. В зависимости от длинны паузы между повторениями, или происходит, или не происходит очистка кеша, что напрямую влияет на задержку вычисления/записи. Когда очистка кеша происходит, то тут два варианта, или это происходит по таймауту, или в результате переключения контекста ЦП. Тут подходим к основному вопросу. Есть ли возможности управлять первым или вторым средствами ОС или средствами приложения, или же это полностью аппаратная логика?

[Pavia]

Когда очистка кеша происходит, то тут два варианта, или это происходит по таймауту, или в результате переключения контекста ЦП.

Вы забыли третий вариант. Естественный процесс само очистки кэша. Кэш это очередь первый вошел последним вышел.
Тайм-аута нет иначе кэш был бы ещё более сложным и потреблял бы ещё больше энергии.
При переключении процессов происходит принудительная очистка кэша. Правда не факт, что всего.
Смена контекстов происходит при приходе прерывания, а также если приложение само отдало свое время.
Если пришло прерывание таймера (частота 1 мс), то при смене контекстов может переключаться не только поток но и процесс. Это может сильнее влиять на кэшь.
При вызове WinAPI смена контекстов может происходить, а может и не происходить. Причем для ускорения обычно не происходит.

Можно принудительно сбросить кэшь, но только из ядра ОС, нужно писат свой драйвер.
Можно запретить прерывания, но опять таки из ядра.
Можно указать, что закэшировать - доступно везде.

[CRobin]

Что значит указать что закешировать? Могу ли я закешировать функцию, которую вызываю нечасто, но хочу получать ее результат в реальном времени?

[Mirage]

Вот это и есть префетч - периодически (во время задержек) почитывать область памяти, куда происходит запись.

[CRobin]

Mirage как быть если это системная функция типа Send?

[Mirage]

Это - это что?

[CRobin]

Это - это что?

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

[Pavia]

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

Вызвать её с 0 длиной. Только смысла в её кэшировании нет.