Сколько тактов необходимо P4 для полного окончания операции записи? В одной части алгоритма принципиальна обработка даных единичными 16-ти битными словами, для другой важна возможность обработки тех же даных блоками по 8 слов для увеличения производительности. Для сведения к минимуму влияния Store-to-Load Forwarding Penalties данные сначала накапливаются в буффере а потом уже передаются для дальнейшей обработки. Вот собствеено и вопрос - сколько же тактов должно пройти после записи 16-ти разрядного слова в память дабы последующая загрузка в MMX или XMM регистр с того же места не была заблокирована? По моим опытам при среднем растоянии в 100 тактов между записью и чтением блокировка возникает в 10% случаев
Да кто ж его знает "сколько точно в граммах вешать" Это скорее вопрос к скрупулезным исследователям типа Фога или kaspersky (только он похоже потерял интерес к оптимизации и не торопится отвечать на твои вопросы Ну а из того что есть - у Фога для P4 мелькает цифра 10-20 тиков штрафа, в IA-32 просто типа penalty is related to pipeline depth... Можно конечно самому померить "кое-как", но тут проблемка с достоверностью результатов, т.к. не совсем понятно как влияет cpuid перед вторым чтением rdtsc на общую задержку при наличии в тесте записи в память. А если закрыть на это глаза и использовать cld вместо cpuid, то у меня на Northwood'e получается около 28-32 тиков - как по методу kaspersky, так и путем сравнения результатов чтений с выполнением и нарушением условий форвардинга. Но ес-но этот результат получается в "лабораторных" условиях, когда задержка организуется на быстрых операциях типа nop или sub r,r. А в общем случае можно получить и меньше (за счет ограничений ресурсов) или существенно больше (за счет очереди тормозных операций). Вот наглядный пример. Если при измерениях по методу kaspersky организовать задержку на операциях записи (как собс-но он и делал для P3), то получаем цифру в 24 тика, если на нопах или sub r,r то ~32 тика (~85 мопов), а в случае зависимых shr аж 170-180 тиков (46 мопов). Но в первом сл. явно имеет место ограничение по числу store-буферов (=24 в Northwood), а в случае медленных shr моп чтения на самом деле выполняется намного раньше кучи предшествующих shr, застрявших в очереди планировщика Slow_1 длиной 32+12 = 44 мопа
То, что при наличии записи в память cpuid дает завышенные результаты - понятно. Cpuid должна гарантировать выход в отставку всех предыдущих операций. При отсутствии записи в память, операции идут в отставку практически сразу после исполнения, поэтому результаты измерений с cpuid соответствуют времени исполнения куска кода. Отставка же операций записи специально задерживается для обеспечения store-to-load форвардинга. В реальном (нормальном) потоке команд эта задержка как правило не проявляется и ее можно не учитывать (она влияет только на штрафы за нарушение условий форвардинга). Но при использовании cpuid при измерениях эта задержка "вылезает" и дает завышенный результат - это понятно. А непонятки возникают в тонкостях поведения cpuid. Например, на том же Northwood'е одиночная запись с cpuid дает "магические" 24 тика, хотя по другим методикам время отставки оценивается на уровне 28-32 тика. Разница небольшая, но она м.б. вызвана тем, что cpuid может форсировать сброс буферов записи в кэш ("force the processor to complete ..."), по сравнению с обычным режимом. Но еще непонятнее, получается с форвардингом. При нарушении условий форвардинга задержка между записью и чтением при малом числе нопов или sub r,r держится на уровне 68 тиков, а затем скачком уменьшается до 56 = 24+32, т.е. через ~30 тиков запись уходит в отставку, данные попадают в кэш, откуда и считываются без всяких пенальти. Но вот почему магические 24 тика не исчезают, не понятно - ведь после отставки чтения store-буфер уже пуст и cpuid нечего ждать. Реплеем и прочими stall эту доп.задержку не объяснишь, т.к. замена cpuid на cld дает чистые 32 тика. Такое ощущение, что несмотря на очистку store-буфера, процессор "помнит" о том, что была запись и для гарантии делает какие-то проверки (число 24 "магически" совпадает с числом store-буферов в Northwood - по тику на буфер ?)
