Полигон-2

[q]

Интересно что на скорость влияет и то, как кэш отлючать, через CR0 или TR12

[/q]

А ещё можно (раз уж затронули P6) использовать MTRR и поставить всю память в режим uncacheable. и посмотреть, что будет

[q]

А в мане Интела сказано

[/q]

Цитируйте уж полностью (я ещё в прошлый раз на этот момент обращал внимание):
Note that the contents of the instruction and data caches are not affected by the state of TR12.CI, e.g., they are not flushed. The second level cache test sequence should be: set TR12.CI to 1, flush the internal caches, run the second level cache tests
Т.е. на момент отключения кэша уровня 1 часть вашего кода (скорее всего большая) и данных всё равно в нём остаётся и замедление из-за доступа к памяти коснётся только тех данных и инструкций, которых в нём нет.

CR0 также требует после себя явного сброса кэша, ибо:

[q]

To completely disable the cache, the following two steps must be performed:
1. CD and NW must be set to 1.
2. The caches must be flushed.
If the cache is not flushed, cache hits on reads will still occur and data will be read from the cache. In addition, the cache must be flushed after being disabled to prevent any
inconsistencies with memory.
Write hits update the cache, but do not access memory.

[/q]

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

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

Закопипаситив инструкцию mov al, [di] пол сотни раз сделал специально жирную процедуру и запустил прогу с отключенным кэшем данных.
так вот разница выполнения "жирной процедуры"с кэшем данных и без около 30 раз.

Вобщем результаты:

Все включено:
Чтение одного байта в цикле: 0.5сек
Чтение с форсированным промахом: 2.2сек
Чтение одного байта "жирной процедурой": 3 сек

Выключен дата кэш:
Чтение одного байта в цикле: 2.7сек
Чтение с форсированным промахом: 2.7сек
Чтение одного байта "жирной процедурой": 100 сек (!!!)

получается, что при отключеннии кэша данных замедление работы зависит не только от скорости доступа к данным, но и от размера кода. Это надо обдумать

Ну и вишенка на торте: при чтении из области данных БИОС (400h:0) пофигу, включет дата кэш или нет.

[q]

Проц видит 32 инструкции"mov al, [di]" без изменения адреса, и вместо того, чтобы честно выполнить чтение 32 раза, инициирует 1 ИО в память мимо кэша, а 31 операцацию тупо пропускает.

[/q]

Не только адреса, но и содержащихся по нему данных.
Всё верно - MESI-протокол.
При чтении обращение к памяти будет только в том случае, если соотв. строка кэша помечена как Invalid (т.е. данных в кэше нет или они были изменены в памяти кем-то другим). Иначе - данные всегда берутся только из кэша.
В вашем случае состояние Exclusive, и после первой операции никаких обращений к внешней шине в принципе не будет.

от я валенок, на 0 ошибся. цикл 100 раз проганял, а в таблице посчитал как 1000.
теперь никаких чудес.

Еще один интересны момент по отключению кэша кода (колонка Е)

Цикл с одним "mov, al, [ds]" и с четырьмя выполнятеся прибилзительно одно и тоже время. Хотя во втором случае надо перегнать в 4 раза больше данных.
При дальнейшем увеличении тела цикла время исполнения постепенно растет.
Очень похоже, что когда тело цикла кототкое (от 1 до 4 операций mov) то код в префетчер доставляетя за 1 такт (т.к. шина 64 бита, а операция mov 2х байтная, соответсвенно в 64 бита влазит 4 mov'а)