Полигон-2

Я так понимаю, дело тут в том, что x86-процессоры начиная с 486 (и Pentium, в том числе), очень сильно зависят от кэша L1, из-за своей конвеерной архитектуры.

Вот нашел список всех MSR, если вдруг кому надо:
https://github.com/cirosantill...1c/MSR.LST

Действительно раздельное выключение L1 кода и данных есть только у P-MMX:

[q]

MSR 0000000Eh - Pentium, K6, C6 - (TR12) NEW FEATURE CONTROL
...
Bit(s)\tDescription\t(Table R0014)
...
20\t(PentiumMMX only) Data Cache Inhibit (disable internal data cache)
19 (PentiumMMX only) Code Cache Inhibit (disable internal code cache)
...

[/q]

pahan написал:

[q]

Если источник данных (память) будет работать на частоте 25 МГц...

[/q]

Теоретически правильно. Но в данном конкретному случае
во первых, и память у пенька пошустрее
во вторых, шина поширее
в третьих, очередь префетчера подлинее

так что деградация до уровня 386-25МГц, как по мне, может быть вызвана только какими-то дополнительными расходами, вызванными отключением кэша. Мне кажется, даже при отключенном кэше, любой доступ к памяти начинается с cache lookup который естесвенно ничего не дает. И только после этого проц начинает операцию ввода вывода к памяти.

[q]

Мне кажется, даже при отключенном кэше, любой доступ к памяти начинается с cache lookup который естесвенно ничего не дает.

[/q]

Скорее всего, вы правы. Изначально (при старте процессора) кэш отключен. Но дальше он включается, кэширует какие-то данные, и к тому моменту, когда мы отключаем кэш из тестовой проги, в нём уже что-то есть. А вот дальше самое интересное - даже при отключенном кэше, в случае если нужные данные находятся в нём, они будут взяты из кэша, но в случае промаха кэш обновлён не будет. В случае записи - они могут быть обновлены только в кэше, но не в памяти.
см. Pentium® Processor Family Developer’s Manual 24142805.pdf таблица 2.1

[q]

во первых, и память у пенька пошустрее

[/q]

Не так уж и сильно - в 2-2,5 раза.

[q]

во вторых, шина поширее

[/q]

А это вообще мало влияет. Ну протаскивает он за такт в 2 раза больше данных. Только программе (особенно досовской) из 32/64 бит при этом скорее всего надо было только 8 или 16. Остальные будут проигнорированы. Широкая шина как раз актуальна в основном чтобы загонять данные в кэш.

[q]

Естественно на лукап уходит как минимум 4 цикла (а то и больше).

[/q]

Откуда цифра 4? Минимум 4 цикла - это как раз обращение к памяти уже после кэша.

[q]

во первых от широкой шины выиграет префетчер (по крайней мере в теории)

[/q]

Да, в теории в 2 раза. В лучшем случае. Префетчер у классического пня - 2 буфера по 256 бит (т.е. в р-р строки опять же кэша). Одновременно работает только один, но он хотя бы будет качать вдвое быстрее. У MMX - 4 по 128 бит, что этот теоретический выигрыш убирает (качать 256 бит по 64 битной шине - тоже самое, что и 128 бит по 32битной).

[q]

Во вторых FPU.

[/q]

Тоже теория. FPU 1) не так уж часто и используется, а только там где он действительно нужен и 2) работает с 32, 64 или 80битными данными. Выигрыш дадут только два последних варианта.

Поставил конвингтон, чтоб Л2 кэш под ногами не путался.

Получилось
Включенный кэш:
Последовательная запись: 0.17с
Последовательное чтение: 0.16с
Запись с форисрованным промахом кэша: 0.77с
Чтение с форисрованным промахом кэша: 0.39с

Выключенный кэш:
Последовательная запись: 14.6с
Последовательное чтение: 18.0с
Запись с форисрованным промахом кэша: 15.2с
Чтение с форисрованным промахом кэша: 17.9с

Короче говоря, процу проще сделать кэш лукап+лайн филл чем с отключенным кэшем к памяти обращатся. Вот собственно и вопрос, откуда такой оверхед на отключенный кэш.