Полигон-2

Замечательная программа SetMul (http://www.vogons.org/viewtopic.php?t=38613) помимо всего прочего имеет такие ключи:

[q]

-Pentium P54C test register "TR12" options. Parameters:
BPD - Disable Branch Prediction
VPD - Disable V Pipeline
L1DX - Disable L1 cache exclusively
CCD - Disable L1 code cache
DCD - Disable L1 data cache
PFE - Pentium Features Enable; Resets the above TR12 options to default.
The status of register TR12 cannnot be read by design.

[/q]

То есть на Pentium P54C можно выключить предсказание ветвлений, V Pipeline, и отдельно отключать кэш L1 для кода и кэш L1 для данных.
Вот тут (https://www.vogons.org/viewtopic.php?t=47590&p=490976) товарищ пробует это дело на Pentium Overdrive 200.
Ниже там пишут, что на обычных MMX Intel уже убрала эти регистры TR12, и они уже не работают. Так же пробуют эти ключи на Pentium 120 - опять неудача. А вот на P90 - работают.

Пробовал ли кто-нибудь играть с этими регистрами? Как отражается на производительности? На каких процессорах они есть, на каких уже нету?

Наверное на OD как раз и были эти регистры для снижения производительности, типа турбы, для совместимости.

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

[q]

А какой практический смысл?

[/q]

Как всегда - спортивный интерес
Интересно, обгонит Pentium 486-ую машину без этих своих branch prediction и V Pipeline на одной частоте )
FSB допустим сделать 50MHz и на четверке можно, и на Pentium... И посмотеть, кто кого

[q]

Как показала практика из пенька этими переключалками можно инвалида сделать ))))

[/q]

Всмысле? Насовсем?
Глядите-ка без L1-кэша кода он медленнее, чем без L1-кэша данных )) Код важнее )

pahan,

pahan написал:

[q]

что со временём 386го мало что изменилось.

[/q]

Ну частота ядра и шины уж точно изменилась

По такой логике получатся что если разогнать 386 25МГц до 66МГц то произовдительность все равно будет как у 25МГц

Если источник данных (память) будет работать на частоте 25 МГц, не столь важно, на сколь огромных частотах будет обрабатывать их ядро процессора. Что все давно видели на примере коппермайнов и нортвудов (особенно целеронов), когда рост только частоты ядра давал уменьшающийся почти до нуля рост производительности.

[q]

Глядите-ка без L1-кэша кода он медленнее, чем без L1-кэша данных )) Код важнее )

[/q]

Вот именно что важнее интерпретация результатов. Имхо, всё зависит от конкретной задачи (теста). В 3D тестах вычислений много - важнее кэш кода. В speedsys - важнее кэш данных (скорее всего, там какие-то СУБДподобные задачи - типа выбрать определённые строки из большого однотипного массива).

Грубо говоря, скорость кэша в 10 раз выше скорости памяти (особенно по задержкам), вот и производительность падает в 10 раз )

pahan написал:

[q]

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

[/q]

Вот именно, то есть при прочих равных у нас получатеся какой то условный 386ДХ-66. А получился 25.


pahan написал:

[q]

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

[/q]

Это по сути потдверждает мою теорию. Т.е. не смотя на "отключенный кэш" проц все равно не имеет обходных путей для общения в внешним миром в обход кэша.
Т.е. при любой ИО операции к памяти проц сначала проверяет есть ли эти данные/код в кэше, и (кто бы мог подумать) их там не находит. Естественно на лукап уходит как минимум 4 цикла (а то и больше).
Т.е. кэш становится тормозом системы, а не ускорителем.

Поэтому я и говорю, что проц без кэша и проц с отключенным кэшом это не одно и тоже.


pahan написал:

[q]

А это вообще мало влияет. Ну протаскивает он за такт в 2 раза больше данных.

[/q]

Тут тоже не все так просто, во первых от широкой шины выиграет префетчер (по крайней мере в теории). Во вторых FPU.

дошли руки немного поиграться с отключением кэша. получилась полная ерунда.

под руками оказался Пень2 266 на 440LX.
для начала написал на паскале простенький код, который заполняет память определенными значениями, а затем их читает.
доступ к памяти осуществлялся двумя способами
- последовательно. т.е. идеальный для кэша режим
- и с чередованием в 128 байт. т.е. каждый последующий доступ должен с высокой долей вероятности вызвать промах кэша.

естественно в первом случае программа работала в 4 раза быстрее, чем во втором.

Затем отлючил оба кэша. И тут началось самое интересное.
Во первых программа стала тупить не по детски. работать стало медленне раз в 50.
Но самое смешное, что таймер стал тупить. Т.е. программа рапортует что выполнялась 5 сек, когда в реальности это было больше минуты. Один раз время даже отрицательное получилось
Такое впечаление, что прерывание таймера не всегда отрабатывается. Хотя может у паскаля какие то свои тараканы по поводу таймера, но с другой стороны с кэшем же все нормально работает.

UPD. С таймером это я тупанул

[q]

Вот собственно и вопрос, откуда такой оверхед на отключенный кэш.

[/q]

Думаю, с этим всё просто - к моменту разработки этих процессоров никто и не предполагал возможность их эксплуатации без кэша. Собственно, ковингтон - короткоживущий маркетинговый ублюдок, выросший из стремления максимально удешевить процессор и быстро провалившийся. Да и вообще, почти все нововведения в P6 (как и в P54) просто бессмысленны без кэша.

Но изначальный-то спор у нас был вообще-то про P54(С). Вот на нём бы посмотреть замеры. Интересней как раз было провести этот тест на 286-586х - посмотреть, насколько отстутствие кэша будет влиять на производительность в разных поколениях.

[q]

кстати, у меня где то мамка сокет3 есть, так в ней в биосе отключение л1 кэша отнесено к режиму "детурбо".

[/q]

Ага, он так обычно и реализовывался.

[q]

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

[/q]

Э нет.
Тут как раз интересно смотреть на самые древние и самые дешёвые.
286 и 386SX, когда на платах его просто могло не быть.
486 - особенно интересны поделия от Cyrix, когда для включения встроенного в процессор в кэша должна быть поддержка в биосе.
486-P5 - наши "любимые" платы с фейковым кэшем. Как вариант - платы без набортного L2 кэша и только с (пустым) разъёмом под COAST.

Fasterpast написал:

[q]

486-P5 - наши "любимые" платы с фейковым кэшем.

[/q]

Есть вполне себе брендовые 486-е с опциональным L2 кэшем "хрен найдешь".
И не скажу, что производительность без кэша падает катастрофически.

дело в том, что с внешним кэшем я таких тормозов не наблюдаю. как вы правильно заметили, внеший кэш может как присутсвовать, так и отсутсвовать - оба режима штатные. поэтому его наличие/отсутсвие дает более менее прогнозируемые результаты. а вот отключение Л1 кэша дает жесткий тупняк.

Проверил на 166ММХ без л2 кэша

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

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

Внешний кеш поддерживается чипсетом, и даже в описании чипсетов (от Intel, да и других)
указано что "cacheless configurations also supported". Те это вполне штатный режим, тогда как
в P6 уже dual independed bus. Добавлю, что эффективность внешнего кеша на плате намного
ниже (и не только из-за частоты!), поэтому и выигрыш от него (и проигрыш при отключении) не
такой большой.

[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'а)