Ну ты даешь! ;-)) У меня челюсть до низу отвисла когда я увидел СКОЛЬКО
текста! Достаточно страницы указать! Есть у меня этот мануал, другим ссылку можно дать. Да и отвечать теперь неудобно.
>Из чего делаю вывод: MMX & SSE - FPU sharing, SSE2 -
> independent. Т.е. при работе с 128 битовыми целыми - все
> хорошо, а с 64 битовыми напряженка.
Непонятен вывод, т.к. непонятно откуда он.
MMX&SSE а также SSE2 разделяют блоки, которые выполняют
эти команды, но не регистры.
> При этом, насколько я
> понимаю, из описания и доки, то ССЕ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.
> Со сдвигом согласен, если его только не осуществлять через
> сложение умножение.
Не понял. А как еще его можно реализовать?
> А для других операций - тут пардон.
> Кроме того, целочисленные операции имеют свои коды FIADD,
> FIDIV, etc. Используя их не надо переводить процессор в
> режим округления специальной командой.
Надо. Дело в том, что целочисленные операции работают в режиме округления к нулю, или проще говоря отбрасывают неуместившиеся
в мантиссу биты. Если ты сложишь 2 числа, возможно переполнение,
и тогда результат должен быть в точности такой, как если бымы взяли его точный и отрезали нужное количество бит. Но по умолчанию стоит режим округления к ближайшему, поэтому FIADD в половине случаев будет давать
результат отличный на единицу.
> Это вещи известные, только вот операции умножения очень
> дорогие.
Насколько дорогие? Миф это. Тот же самый как и отсутствие аппаратного
ротейта в P4.
> Дык, никто и не спорит, только сильно глюкавая она:
> Если посмотреть мой первый пост, то там ссылочка на днет -
> про тоже и говорит - 4 такта ожидания дополнительно.
Через 4 такта результат ротейта готов. В нашем случае
все данные должны сидеть в кэше, поэтому пеналти маловероятны.
При оценке производителности их даже не учитывают.
> А сам
> Интел советует заменять сдвиги влево на 1 на сложение.
Сложение стоит 0.5тактов, сдвиг 4. Так было всегда - я имею
ввиду сложение лучше чем сдвиг. Вопрос на сколько. Когда
последователность сложений выгодней использовать чем сдвиг.
Посмотри исходники ядер - не найдешь там ни одного сдвига.
Только ротейт.
>И
> еще - посмотри, что происходит, если операнд в памяти, а не
> на регистре - еще 6 тактов.
Данные в кеше. Штрафов нет.
> PS Я не слишком напрягаю народ, когда цитирую на английском
> языке в таком количестве? Если что, то пинайте, я обещаю
> исправиться.
Пинаю!! ;-)) Дважды я не смог ответить потому, что непонятно было где
в тексте мысль, а где мусор.
|
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
