Кэш процессора

Вот и настал момент озадачится по взрослому...

Оптимизация кода компилятором и оптимизация кода даже самим процессором. Оптимизация это представление порядка получения команд.

Как-то странно оказыватся получается : хочет поцессор как лучше и меняет порядок выполнения команд, то есть по мнению процессора он оптимизирует время выполнения , то есть хочет сделать как лучше...

И компилятор тоже этим грешит - тоже хочет сделать как лучше, а получается как всегда.

Вывод - нельзя верить ни чему и надо проверять все на ассемблером коде?

Для компилятора да - можно так развлекаться , но как проверить оптимизацию кода процессором в его личном кэше?...

Начинаем изучать тему: как в с++ и в с можно запрещать процессору и компилятору переставлять команды:

Аббревиатуры:
RMW read modified write
CAS Compare and swap
FAA fetch and add
TAS test and set
LL/SC load linked/ store conditional
L линия кэша состоит из L байт
SMR safe memory reclamation

Атомарные операции как раз и будут запрещать перемешивать команды.

automatically

LL/SC используется в ARM
CAS используется в x86

Как выясняется далее процессор сначала обращается к своему кэшу для для поиска данных по нужным адресам. Работает поцессор блоками размером с cach line.

Так вот самое интересное это кто рулит управлением кэша , как он это делает.

coherence (синхронизация) кэш разных ядер одного процессора это теперь настоящая головная боль.

MESI (Modified Exclusive Shared Invaled) протокол когерентности кэша для Intel Pentium, Power PC,...