Планирование потока инструкций

Цикл, который я пытался анализировать был все же посложнее Теперь с твоим объяснением все стало на свои места. Я думал, что мопы раздваиваются после стадии Dispatch, а на деле каждый из них проходит через Dispatch как полностью независимая операция.

Приведенные четыре команды выполнялись в цикле, который подымал данные из исходного изображения и переписывал в локальный буфер, для всей последующей обработки. Поскольку кодер реально работает со словами, то исходные беззнаковые байты распаковывались punpcklbw/punpckhbw в слова, из них вычиталась постоянная составляющая, и результат записывался в локальный буфер. Т.е. цикл и так активно работал по пересылкам, вот и было интересно - имеет ли смысл перекинуть dc_corr в один из регистров, тем самым теоретически понизив нагрузку на L1 кэш. К слову, описанная переделка немного улучшила ситуацию с количеством тиков на входной байт, но не кардинально

BTW, тестировал свой код на CoreDuo 1.83ГГц. По тестам одно ядро CoreDuo 1.83GHz эквивалентно P4 3GHz При активации HyperThreading P4 увеличивает свою производительность на моем коде в полтора раза, активация же второго ядра в CoreDuo добавляет еще 90-95% производительности. Таким образом заурядный двухядерный ноутбук легко "делает" mainstream десктоп Ну и любимый тест - AMD vs Intel В наличии был Duron 1.1GHz - его производительность оказалась сопоставима с P4 1.8GHz Northwood. И это при том, что я даже в первом приближении не пытался оптимизировать свой код под AMD. Кто сказал, что AMD делает плохие процессора ?

 

leo

А как в случае:

Код (Text):

1. FLD  [MyVar]
2. FADD / FMUL / и т.п.
3. FSTP [MyVar]

где конструкция типа add [MyVar], ... не предусмотрена?
Или это исключительно "model specifed" P4 model 2 (Northwood)?

 

Y_Mur

В первых P4 эта проблема наиболее сильно выражена, т.к. у них штраф за реплэй довольно большой. В других пеньках преждевременное чтение тоже возможно, но и допустимая дистанция и штраф за переисполнение чтения меньше. Ну а в атлонах, как я уже говорил, такой проблемы нет, зато есть AGI за счет строго последовательного вычисления и анализа адресов чтения и записи. (Хотя существует еще и другая проблема и на атлонах тоже - ошибка store-to-load forwarding'а, когда чтение производится "по совершенно другому" адресу, но за счет частичной проверки разрядов адреса схема SLF дает псевдо-hit с предшествующей записью)

Никак Только увеличением дистанции между записью и чтением - или за счет перестановки инструкций или за счет добавления нопов. А еще лучше просто работать с регистрами и не дергать попусту память )

 

leo
Спасибо - значит буду увеличивать дистанцию перестановками
Такие конструкции у меня конечно не в критических местах кода, а только там где требуется изменить блок настроек, но всё равно хочется красоты - чтобы сама мысль на уровне генерации более менее оптимального кода работала )

 

leo
Кстати, о RDTSC. Похоже на Core2 у него тоже дискретность 8.

 

/можете засмеять)/
Но, судя по моим юзермодным тестам - дискретность на коре2 1.

 

Ustus, asmfan
Мне в обозримом будущем видимо не светит это чудо пощупать
Так что рассудить не могу

PS: Может 8 тиков rdtsc это и есть все "лучшее", что было взято из бесценного опыта NetBurst ?! Наверное на 0.00..1% тепловыделение удалось снизить )))

 

leo
"Не надо печалиться... надейся и жди!"(с)?
А с 1 это я погорячился - ибо в цикле тесты высе выполнял, а там отлично сработало усреднение... т.е. на ноп (несколько нопов) был чётко видел шаг в 1. А с единичными прогонами число 7 да 15 выпадают... выходит от 8 и 16 недалеке... т.е. Ustus, судя по всему, прав.

 

leo
Если надо проверить какие идеи - я завсегда готов!

asmfan

ну так это вобщем-то и правильно...