Pull to refresh

Comments 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)  
  }

Сейчас проверю последний раз этот пример я запускал 2 года назад. Наверное, -fast-math включился, он отбрасывает denormals. Но код вроде правильный сгенерился.
У меня были примеры с денормалами. И если на SB & YB они нормально тормозили, то на haswell все стало быстро как с нормальными числами.
да, я что-то код сверху не могу заставить тормозить, исполняю как раз на HSW. Схожу в лабу на SNB проверю, как раз выдран с реального кода на SNB.
Ну еще совсем простой пример. David Dice рассказывал про случай, когда просто доступ к чужой NUMA пямяти на 8-сокетной системе (за 2 хопа) занимал > 1000 тактов.
О, а вы в лабу ногами ходите?! :)
Только чтобы подключить старое железо — старше broadwell и skylake, или редкое/мелкое. Весь зоопарк постоянно держать подключеным места не хватает, да и зачем — очень редко нужно.
div [memory]?
Ну хотя тут десятки тактов, даже если кэш-промах.
Еще вариант — syscall / sysenter. Там сотни тактов, емнип.
Да, десятки и сотни, все примеры из статьи кроме fy2x — тысячи.
FYl2X — я так понимаю, параллелится с обычными инструкциями на ура?
Эта инструкция декодируется в длинный микрокод, так что нет (то есть этот микрокод, понятно, ипользует ILP внутри себя, но следующие инструкции ждут).
Хм. А я думал что FP ядро слегка независимо от целочисленного. Отстал от жизни на пять поколений процессоров, видимо :D
В Atom еще почти независимое. Но даже там в этом микрокоде полно load/store, которые занимают обычные порты. а в HSW core просто 8 портов, некоторые содержат в том числе execution units, работающие с fp.
То есть старый трюк «бесплатной» плавающей точки исчез в результате интеграции, зато большинство инструкций стало просто не настолько медленные, так?
Неужели логарифм по основанию 2 так долго считается? Есть ли аналоги для расчёта логарифма? AVX и SSE содержат что-либо для расчёта тригонометрических и экспоненциальных функций? Или только приблизительно можно считать?
AVX и SSE содержат достаточно простые инструкции. Скорее всего, если на них написать свой логарифм, может быть быстрее.
Неужели эти инструкции медленнее чем WBINVD?
WBINV надо быть в ring 0, ее неожиданно в пользовательском коде оказаться не может. Кстати, она сама не очень медленная, тормоза начинаются потом, когда оказывается что кэш пустой.
А вот вопрос, зачем ты в последнем примере делаешь цикл на 8К? ;)
Сдается мне, что тут ты сгущаешь краски ;)
А, это от vtune осталось, иначе ивенты не ловились. Конечно можно один раз померить, будет несколько тысяч циклов. Спасибо, поправлю.
этот код заставит все остальные ядра тоже остановиться на перекур на срок в несколько тысяч тактов


Как это будет себя вести в VM? Можно заДОСсить соседей по VM?
Можно, даже если другие VM работают на других ядрах. Но для многопроцессорного сервера — только соседей по процессору. VM можно запрограмировать это ловить и давать таким гостям совсем мало тактов, но вроде это нигде пока не реализовано.
Насколько я понимаю, что с того момента, когда Intel похоронила SMP, самые дорогие операции — это операции связанные с инвалидацией кешей у «соседей».
Да, выше уже написали, что еще это может быть особенно дорого на Xeon-EX, там NUMA особенно злая.
А какова разница «по скорости» между LOCK CMPXCHG и LOCK XADD?
Если с splitlock как в примере, то несущественная. Если без сплитлока, надо измерять, не знаю так.

(некрокоммент, но дали ссылку на статью как аргумент)


Злодей номер два.

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-го надо было учесть и новые тенденции.

Sign up to leave a comment.