нужны числа 0x00000000 - 0x99999999, не содержащие буквы [A..F]

S_T_A_S_

Не пойму, о чем ты.

Если о результатах теста, то на цикл из 1000 проходов получается:

Код (Text):

1. Проц Модель   2 сдвига  1 сдвиг
2. ---- ------   --------  -------
3. P3   6.8.6    ~12000    ~9000  ;~ т.к. единицы\десятки не помню, а в сей момент P3 под рукой нет
4. P4   15.2.7    14040     9040

PS: на всякий случай поясняю: чтобы не сломать голову и получить число тиков на цикл нужно отбросить единицы и десятки (это тики на вход\выход из цикла) и разделить результат на 1000. Получим х и y.



bogrus

Может приведешь результаты на своем P3 ?

А то боюсь S_T_A_S_ и себе голову сломает, и мне проломит



Кстати в варианте с одним shr условия декодирования хуже, т.к. jnz разбивается по границе 16 байт, а в варианте S_T_A_S_ как раз все идеально. Откуда же 3 тика ? Да и декодирование-то не должно влиять, т.к. все инструкции одномоповые и не разбиваются на границах => декодирование идет практически в 3 раза быстрее исполнения.

 

leo



Спасибо, это как раз то, о чём я писАл несколько постов назад

Тепеь можно делать какие-то выводы: лишний shr увеличивает время выполнения на P6 на треть.





Nitroz >

Это хорошо, буду развивать способности: уже нашёл объявление "для высокооплачиваемой работы требуются ясновидцы, куда обращаться сами знаете"

 

S_T_A_S_ > "лишний shr увеличивает время выполнения на P6 на треть"



Ты все прикалываешься ... Если бы код занимал ~ 6 тиков, то на половину, а при 12 на четверть и т.д. ???

 

9000 * 4 / 3 = 12000

 

На PIII shr r,i занимает 1 моп (как и другие команды из этого теста), и похоже здесь больше влияет не декодирование, а исполнение, чтобы точно разбросать такты, нужно ещё почитать Фога и провести кое-какие тесты

Код (Text):

1. ====================================================================== ===============
2. адрес       опкод    инструкция         длина мопы декодер порт a/ т b/ т
3. ====================================================================== ===============
4. 00401490 |>  8D82 67666666 |/LEA EAX,[EDX+66666667]| 6    1    D0  1   p0   p0 1 p0 1
5. 00401496 |.  09C2      ||OR EDX,EAX        | 2    1    D1      p01  p1   p1
6. 00401498 |.  31C2      ||XOR EDX,EAX       | 2    1    D2      p01  p0 2 p0 2
7. 0040149A |.  81E2 88888888 ||AND EDX,88888888      | 6    1    D0  2   p01  p1   p0 3
8.  
9. 004014A0 |.  31D0      ||XOR EAX,EDX       | 2    1    D0  3   p01  p0 3 p0 4
10. 004014A2 |.  C1EA 02       ||SHR EDX,2         | 3    1    D1      p0   p0 4 p0 5
11. 004014A5 |.  2D 66666666   ||SUB EAX,66666666      | 5    1    D2      p01  p1   p1
12. 004014AA |.  31D0      ||XOR EAX,EDX       | 2    1    D0  4   p01  p0 5 p0 6
13. 004014AC |.  89C2      ||MOV EDX,EAX       | 2    1    D1      p01  p1   p1
14. 004014AE |.  49        ||DEC ECX           | 1    1    D2      p01  p0 6 p0 7
15. 004014AF |.^ 75 DF     |\JNZ SHORT 00401490    | 2    1    D0  5   p1   p1   p1 8
16. =====================================================================================

И так и сяк декодирование не получется больше 5 тактов, в последнем блоке 3 декодируемые группы, значит задержки декодера не возникает, цикл выровнен и "стабильный", плохо, что иногда декодеры D1,D2 пустуют, но вот с портами огранов исполнения не совсем понятно ... Если наложить правило a:

<font color="red]"В большинстве случаев каждый порт может получать один моп за такт. Это означает, что вы можете выполнять до 5 операций мопов за такт, если они попадают в пять разных портов, но так как есть ограничение на 3 мопа за такт, установленное ранее в конвейере, вам никогда не удастся выполнить больше 3 мопов за такт в среднем."</font><!--color-->

То можно найти 6-й такт, если наложить правило b:

<font color="red]"Следующая проблема с механизмом доставки инструкций заключается в том, что новый БДИ не сгененирируется, пока предыдущий не будет полностью отработан."</font><!--color-->

То их будет уже 8, а где ещё 9-й пока х.з.

 

imho первые три команды не будут параллелиться, т.к. зависят по данным.

на атлоне это так, что и видно на картинке.

 

Та, на атлоне наверное все direct path по одному такту, а для 3пня на "OR EDX,EAX" можно как раз добавить 9-й такт и выполнится он в p0, в других случаях можно не добавлять, "SUB EAX,66666666" независима, а для "MOV EDX,EAX" должно сработать переименование временного EAX в EDX

 

Вот уж где голову сломаешь, так это на попытке понять работу P6 family. Стоит в варианте S_T_A_S_ перед декрементом счетчика dec ecx вставить nop или xor eax,eax как сразу получаем ~10000 тиков на 1000 проходов против 12000, т.е. 2 лишних тика на цикл - долой.

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

 

Ты лучше замени в его варианте "or edx,eax" на "or ebx,eax" (любой не используемый регистр) и обалдей , получишь 8 тиков, т.ч. декодирование проехали, пора переходить к тестированию зависимостей по портам и регистрам

 

Неиспользуемый регистр - это более или менее понятно. Зависимость по портам и регистрам тоже.

Но вот куда нет желания соваться, так это в переименование регистров, работу реордер-буфера и в ретайрмент (ни снаю как эта па рюски - сегодня три раза прочитал на аглицком и понял только в общих чертах. Муть одним словом, мозг слипается и руки опускаются



Теортетически, xor eax,edx и shr edx,1 могут выполняться параллельно если нет конфликта по портам (первоначально я это упустил из виду). Поэтому исключение одного shr при прочих равных условиях даст выигрыш = латентности этого shr (грубо говоря). Ну а на практике можно запросто потерять 1-2 такта, не прилагая особых усилий.

 

Ещё не поняли, что тестить циклы - часто бесполезная трата времени?

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

 

Можно сказать, что любые тесты - бесполезная трата времени, если мы расчитываем получить результат с точностью до тика. Какое будет окружение и выравнивание тестируемого куска в реальном коде ? Неизвестно, отсюда принцип неопределенности в 1-2 тика (ес-но без учета пэйдж-фолтов, кэш-миссов и бранч-предикшенов, иначе вообще труба

 

>

Интересная теория

А на основании чего делаются такие обобщения?



>

зачем это знать? симуляция пайпа показывет вполне достоверную картину.

если добавить ещё команды, то моловероятно, что будет быстрее.

в этом и заключается проблема циклов - тестируется один код,

а на основании полученных результатов, делаются предположения о работе другого.

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

 

> "А на основании чего делаются такие обобщения?"



На основании того, что стоит после запятой: "бесполезная трата времени, если..."



> "симуляция пайпа показывет вполне достоверную картину"

> "если добавить ещё команды, то моловероятно, что будет быстрее"



Во-первых, симуляторы пайпа для P6 и NetBurst мне неизвестны. Может ты знаешь ?

Во-вторых, об атлонах я практически ничего не знаю. Но в P6 family, как тебе известно, существенную роль играет выравнивание и декодирование команд (вспомним тему 4-1-1 µop sequence), а также куча прочей малопонятной фигни, также зависящей от выравнивания и предыдущих команд. То, что при добавлении одной команды на PIII можно получить выигрыш (точнее устранить проигрыш) в 2 тика см. мой предыдущий пост <Фев 7, 2005 22:16:30>. Так что симулятор это хорошо, но симулировать нужно реальный код с реальным выравниванием и окружением, ЕСЛИ мы хотим получить результат с точностью до тика.

 

leo



Естественно, я чител твой пост целиком, но не вижу, где там после запятой основания утверждать, что

.

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



>

Нет. да они наверное и не нужны, все же знают, что пентиумы это суперпроцессоры. а атлоны - фуфло, поэтому для них производитель и предоставляет бесплатную тулзу %)



>

кто же спорит? я как раз про это и говорил, имея ввиду циклы