S70Dimitry Sibiryakov,

извини, конечно, за прямоту. Твой ответ называется "ответом программиста" - абсолютно точный и настолько же бесполезный.
Есть данные. Поступают они с разной интенсивностью, которая в первом приближении - понятна. Когда данные криво лежат, проц постоянно промахивается по кешу, кроме того, забирает из памяти данные, которые ему сейчас не нужны. Как минимум, я хочу разнести данные с разной интенсивностью обновления.
Насколько я помню, L1 кеш имеет/имел линию в 32 байт. Т.ч. все что больше - глубоко пофиг будут рядом или не рядом (TLB пока не рассматриваем).

Про оптимизацию под L2 / L3 кеш я как-то даже и не слышал

Кроме того, в процессоре out of order execution. Если для какой-то инструкции данные еще не прибыли, но есть следующие инструкции которые можно выполнить - процессор все равно простаивать не будет.

Локальные и глобальные переменные модуля (.C файл) - все равно лежат "рядом". Компилятор и будет их размешать ровно так, так они описаны в приложении.

Тут главное не словить промахи при выполнении, но это нужно брать реальное приложение и запускать под чем нибудь типа Intel VTune (пользовался в начале 2000-х). Промахи могут быть совершенно "экзотические" и крайне удивительные. Лично я напарывался на промах обращения к выравненным данным после обращения к невыравненным (алгоритм такой был). Так там наоборот: то что данные попали в одну линию кеша - как раз и было проблемой. Попадали бы в разные линии, промаха бы не было )))

Т.ч. самая главная "оптимизация" не плодить лишних переменных и сущности )))

Если речь идет о выделении памяти через new / mallloc - тут тоже все сказали. Просто выделяйте одну область и ее используйте.

S70Поступают они с разной интенсивностью, которая в первом приближении - понятна. Когда данные криво лежат, проц постоянно промахивается по кешу
Тут ключевой вопрос ОТКУДА и КАК поступают данные.

Если данные поступают по сети - тут не ЯДРО проца по кешу может промахнуться, а прерывание от сетевой карты не на то ядро придти ))) (если проц многоядерный). А при таком "промахе" никакой кеш не поможет, ядро совсем другое

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

Если данные приходят по сети (а она скорее всего TCP/IP) Оптимизировать можно, но тут проблемы AFAIK совсем другого уровня. Взаимодействие железа + прерывания + ядро проца + драйвер + ОС + прикладной софт. Но AFAIK этим занимаются только производители ОЧЕНЬ дорогого и специфического железа. Всякая китайская дешевка ))) типа Ethernet 10 G и их драйвера на такое внимание не обращают. Т.ч. там хоть оптимизируй прикладной соофт хоть нет - ничто не поможет ))). Только выкидывать нафиг устаревший TCP/IP и переходить на что нибудь более современное ))) AFAIK