> Ну ты даешь! ;-)) У меня челюсть до низу отвисла когда я
> увидел СКОЛЬКО
> текста! Достаточно страницы указать! Есть у меня этот
> мануал, другим ссылку можно дать. Да и отвечать теперь
> неудобно.
Почесал ушибленное место и начал путь к исправлению.
>
>
> >Из чего делаю вывод: MMX & SSE - FPU sharing, SSE2 -
> > independent. Т.е. при работе с 128 битовыми целыми -
> все
> > хорошо, а с 64 битовыми напряженка.
> Непонятен вывод, т.к. непонятно откуда он.
> MMX&SSE а также SSE2 разделяют блоки, которые выполняют
> эти команды, но не регистры.
>
По доке выходит, что SSE MMX разделяют регистр состояния - смотри советы по оптимизации, страница 4-2.
> > При этом, насколько я
> > понимаю, из описания и доки, то ССЕ2 с 64 не работает.
> PSLLQ xmm, imm8 - сдвигает 2 64битных числа в xmm-регистре
> Не используй верхнюю часть и все хорошо.
>
> > Вывод делаю - всякие сдвиги - очень дорого.
> Почему дорого?
> PSRLW/PSRLD/PSRLQ xmm,xmm/imm8 2 2
> Т.е. 2 такта. Но и сдвигают они 2 64битных числа.
> Т.е. для свдига 2 64битных чисел на P4 нужно 2 такта.
>
> ROL/ROR 4 1
> А это старые-добрые x86 ротейты. Да 4 такта, но каждый такт
> можно запускать новый ротейт.
> Другой вариант - загнать 4 32битных числа в xmm0 и xmm1
> один сдвинуть влево, другой вправо и сделать логическое и:
> PSRLW/PSRLD/PSRLQ xmm,xmm/imm8 2 2
> PSLLW/PSLLD/PSLLQ xmm, xmm/imm8 2 2
> POR xmm, xmm 2 2
>
> Итого, 2+2+2 = 6. Но мы сделали ротейт для 4 чисел, т.е.
> 1ротейт
> стоит = 6/4=1.5 такта. Вот в чем смысл SIMD.
>
В чем смысл SIMD (а также SISD, MIMD MISD:-) я понимаю, а как насчет того как данные туда попадают? Это тоже надо бы учесть.
>
> > Со сдвигом согласен, если его только не осуществлять
> через
> > сложение умножение.
> Не понял. А как еще его можно реализовать?
>
Если говорить на уровне команд - то да, а на уровне микрокода - просто аппаратным сдвигом (если есть аппаратура).
> > А для других операций - тут пардон.
> > Кроме того, целочисленные операции имеют свои коды
> FIADD,
> > FIDIV, etc. Используя их не надо переводить процессор
> в
> > режим округления специальной командой.
> Надо. Дело в том, что целочисленные операции работают в
> режиме округления к нулю, или проще говоря отбрасывают
> неуместившиеся
> в мантиссу биты. Если ты сложишь 2 числа, возможно
> переполнение,
> и тогда результат должен быть в точности такой, как если
> бымы взяли его точный и отрезали нужное количество бит. Но
> по умолчанию стоит режим округления к ближайшему, поэтому
> FIADD в половине случаев будет давать
> результат отличный на единицу.
>
Тут меня гложут сильные сомнения. Я, конечно, от жизни немного поотстал - бросил возиться с FPU когда вышел 486. Но для 386/387 я писал RTL для компайлеров. Никогда такого не встречал. Может набросаешь мне код, а я проверю его на разных CPU? Чтобы он давал результат отличный на 1.
> > Это вещи известные, только вот операции умножения
> очень
> > дорогие.
> Насколько дорогие? Миф это. Тот же самый как и отсутствие
> аппаратного
> ротейта в P4.
>
ADD/SUB r,r 0.5 0.5
IMUL r32 14 3
IDIV r32 56-70 23
Это не дорого?
Теперь для MMX:
PADDQ/PSUBQ mm, mm 2 1 MMX_ALU
PADDQ/ PSUBQ3 xmm, xmm 6 2 MMX_ALU
PMULHUW/PMULHW/PMULLW3 xmm, xmm 8 2 FP_MUL
PMULUDQ mm, mm 8 2 FP_MUL
Деление SIMD не нашел:-)
Разница и здесь есть.
> > Дык, никто и не спорит, только сильно глюкавая она:
> > Если посмотреть мой первый пост, то там ссылочка на
> днет -
> > про тоже и говорит - 4 такта ожидания дополнительно.
> Через 4 такта результат ротейта готов. В нашем случае
> все данные должны сидеть в кэше, поэтому пеналти
> маловероятны.
> При оценке производителности их даже не учитывают.
>
Я, конечно перечитаю доки еще раз, но у меня сложилось впечатление, что латенси и пенальти вещи разные.
> > А сам
> > Интел советует заменять сдвиги влево на 1 на сложение.
> Сложение стоит 0.5тактов, сдвиг 4. Так было всегда - я имею
Да не всегда - сдвин на 1 был обычно быстрым - таким же как и сложение.
> ввиду сложение лучше чем сдвиг. Вопрос на сколько. Когда
> последователность сложений выгодней использовать чем сдвиг.
> Посмотри исходники ядер - не найдешь там ни одного сдвига.
> Только ротейт.
>
Я не разбирал RC5 досконально, но это может быть вызвано самим алгоримом, а не преимуществами команды. И еще
RCL/RCR reg, 18 4 1
RCL/RCR reg, 18 4 1
ROL/ROR 4 1
SAHF 0.5 0.5 ALU
SAL/SAR/SHL/SHR 4 1
Т.е. я не вижу разницы между сдвигами и вращениями для обычных команд.
> >И
> > еще - посмотри, что происходит, если операнд в памяти,
> а не
> > на регистре - еще 6 тактов.
> Данные в кеше. Штрафов нет.
>
Здесь полностью согласен с тем, что кэш поможет, но есть еще и пенальти за сложные адресации памяти. И здесь надо учитывать не столько саму сложность адресации операнда, а те ложные зависимости между командами, про которые толкует Интел.
> Пинаю!! ;-)) Дважды я не смог ответить потому, что
> непонятно было где
> в тексте мысль, а где мусор.
Ага, по поводу языка возражений нет:-) А про количество - смотри выше.
|
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
