Вот и настал момент озадачится по взрослому...
Оптимизация кода компилятором и оптимизация кода даже самим процессором. Оптимизация это представление порядка получения команд.
Как-то странно оказыватся получается : хочет поцессор как лучше и меняет порядок выполнения команд, то есть по мнению процессора он оптимизирует время выполнения , то есть хочет сделать как лучше...
И компилятор тоже этим грешит - тоже хочет сделать как лучше, а получается как всегда.
Вывод - нельзя верить ни чему и надо проверять все на ассемблером коде?
Для компилятора да - можно так развлекаться , но как проверить оптимизацию кода процессором в его личном кэше?...
Начинаем изучать тему: как в с++ и в с можно запрещать процессору и компилятору переставлять команды:
Аббревиатуры:
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,...