Комментарии 28
Злодей номер два.
Не могу повторить (Intel B960).
Вот этот код выполняется приблизительно одинаковое время при любом значении в fptest.
for (int b = 0; b < 100000000; b++)
{
a += int(2 + fptest);
00231020 movsd xmm0,mmword ptr ds:[233018h]
00231028 addsd xmm0,xmm1
0023102C cvttsd2si ecx,xmm0
00231030 add edi,ecx
00231032 dec edx
00231033 jne main+20h (0231020h)
}
+3
Сейчас проверю последний раз этот пример я запускал 2 года назад. Наверное, -fast-math включился, он отбрасывает denormals. Но код вроде правильный сгенерился.
+3
У меня были примеры с денормалами. И если на SB & YB они нормально тормозили, то на haswell все стало быстро как с нормальными числами.
+2
да, я что-то код сверху не могу заставить тормозить, исполняю как раз на HSW. Схожу в лабу на SNB проверю, как раз выдран с реального кода на SNB.
+1
Ну еще совсем простой пример. David Dice рассказывал про случай, когда просто доступ к чужой NUMA пямяти на 8-сокетной системе (за 2 хопа) занимал > 1000 тактов.
+2
О, а вы в лабу ногами ходите?! :)
0
div [memory]?
Ну хотя тут десятки тактов, даже если кэш-промах.
Еще вариант — syscall / sysenter. Там сотни тактов, емнип.
Ну хотя тут десятки тактов, даже если кэш-промах.
Еще вариант — syscall / sysenter. Там сотни тактов, емнип.
0
FYl2X — я так понимаю, параллелится с обычными инструкциями на ура?
+1
Эта инструкция декодируется в длинный микрокод, так что нет (то есть этот микрокод, понятно, ипользует ILP внутри себя, но следующие инструкции ждут).
+3
Хм. А я думал что FP ядро слегка независимо от целочисленного. Отстал от жизни на пять поколений процессоров, видимо :D
0
В Atom еще почти независимое. Но даже там в этом микрокоде полно load/store, которые занимают обычные порты. а в HSW core просто 8 портов, некоторые содержат в том числе execution units, работающие с fp.
+2
Неужели логарифм по основанию 2 так долго считается? Есть ли аналоги для расчёта логарифма? AVX и SSE содержат что-либо для расчёта тригонометрических и экспоненциальных функций? Или только приблизительно можно считать?
0
Неужели эти инструкции медленнее чем WBINVD?
0
А вот вопрос, зачем ты в последнем примере делаешь цикл на 8К? ;)
Сдается мне, что тут ты сгущаешь краски ;)
Сдается мне, что тут ты сгущаешь краски ;)
0
этот код заставит все остальные ядра тоже остановиться на перекур на срок в несколько тысяч тактов
Как это будет себя вести в VM? Можно заДОСсить соседей по VM?
+1
Насколько я понимаю, что с того момента, когда Intel похоронила SMP, самые дорогие операции — это операции связанные с инвалидацией кешей у «соседей».
0
А какова разница «по скорости» между LOCK CMPXCHG и LOCK XADD?
0
(некрокоммент, но дали ссылку на статью как аргумент)
Злодей номер два.
i3-4170: ~1 нс на итерацию на FPU, 0.5 нс на SSE.
Athlon 64 3500+: 18 нс на итерацию на FPU, 2.2 нс на SSE.
C2D E6550: 100 нс на итерацию на FPU, 0.8 нс на SSE.
Древнее не нашёл :)
1-2 мкс это времена за какой год?
100 нс конечно много, но, извините, это не денормализованные! Это какая-то другая бяка. Скорее всего кривой алгоритм конверсии в целое в случае переполнения.
Денормализованные это (для float) числа менее 1e-38, а таких в данной задаче нет.
Что начиная примерно с Nehalem пошла чистка логики во всём процессоре (и где-то синхронно, хоть и иначе, у AMD), а раньше гнались за герцами — факт. Но для статьи 2015-го надо было учесть и новые тенденции.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Самая медленная инструкция x86