Возникла необходимость посмотреть, сколько тактов в среднем уходит на выполнение простейших арифметических операций у CPU.
Были написаны подобные простенькие функции (в Borland C++ Builder 6):


для add/sub,mul,fadd,fmul,fdiv.
И отдельно функция с пустым циклом для измерения затрат на организацию этого цикла.

Что получилось в результате:
1. FPU у К7 и К8 обладают одинаковыми показателями такты/инструкции (с точностью до 2 знака после запятой). ALU у К7 в 1,5-2 раза медленнее, чем у К8.
2. FPU Pentium MMX медленнее K7 и К8 в 5 раз. ALU - в 2 раза медленнее, чем у К7.
3. ALU Pentium 4 находится между К7 и К8, а вот FPU - в 10 раз медленнее, чем у Pentium MMX.

Насколько справедливы такие выводы? Неужели и правда FPU у Р4 такое жуткое? Может, мне надо было пару лет назад это написать и показать Северу НН?
Или это какая-то ерунда в идее/алгоритме/реализации функции?

не поминай в суе.....подальше от греха

может дело в этом, пока пень подготавливает свой длинющий конвеер к циклу этож уйма времени.
Кроме того, из-за той же причины, выполнение простейших операций также дело доолгое.
инструкция попала в конвеер за 3-4 такта выполнилась, а пока до конца дошла.... скоко у пня ступеней конвеер 20-30, а потом перезагрузка в случае неправильного предсказания ветвления.
В теории можно написать такой код, не шибко сложный но который будет постоянно преводить к перезагрузке конвеера, что теоритически может сделать из пня 4 - пень 2

Tod Schwarzkaiser тут похоже наложилось все. Все-таки цикл, т.е. условные переходы, а это значит прямое влияние эфективности блока предсказания ветвлений.

merlex, Daemon
Относительно предсказания ветвлений у меня было такое соображение: теоретически, если у процессора % правильных предсказаний около 95 и есть некоторый порог срабатывания БПВ, то после некоторого количества итераций предсказание ветвлений значимого влияния не оказывает.
Но могу ошибаться, ибо далеко не бог и не микроархитектор...

Судя по значениям, ALU начинает показывать стабильный результат где-то с 40-48 итераций, а FPU - с 16-24.

Конвейер не будет тут задействован, поскольку (если ) идет постоянное чтение-запись в одну и ту же ячейку FPU стека. Когда-то давно проводил такие опыты, и для того, чтобы P4 мог обогнать K8, надо было использовать чуть ли не весь стек
Предсказания тоже не должны были влиять...тут нет никаких исключений из правил перехода, практически все время переход выполняется.

Может быть по умолчанию разная точность вычислений?

Если я не ошибаюсь, то здесь есть ответ:
http://www.fcenter.ru/online.shtml?arti ... sors/12033

Tod Schwarzkaiser писал(а):

Может, мне надо было пару лет назад это написать и показать Северу НН?

Бесполезно.

S.Q.Lapp

Да... Ответ есть. Но на другой вопрос. А именно - на вопрос про отвратительное поведение П4 в тесте ПСП. Но в данном случае операнды грузятся в регистры до первого снятия TSC, поэтому здесь реплей не должен вмешиваться.

Asteroid

Это намёк на то, что Пень в 10 раз точнее?
И как мне эту версию проверить?

Ещё странно то, что целочисленное умножение почти в 7 раз медленнее у П4 происходит. Странно потому, что, вроде бы, у него Fast ALU есть... Похоже, что оно у него тоже чисто маркетинговое...

Set8087CW( 0x037F ) - Double Extended Precision (64 bits)
Set8087CW( 0x027F ) - Double Precision (53 bits)
Set8087CW( 0x007F ) - Single Precision (24 bits)

Это по IA-32 Intel Architecture Software Developer's Manual Vol. 1 (Basic Architecture), глава 8.

Asteroid

Хорошая идея. Надо будет почитать...

Вот ещё вопрос.
Являются эти последовательности зависимыми или нет?
1.

2.


Результаты по этим цепочкам у К7/К8 такие (64бит; 53бит; 24бит):
AVG (1) FDIV, ticks/op 21,84; 17,84; 13,84
AVG (2) FDIV, ticks/op 23,63; 19,63; 15,63

То есть, это явно не разы - у Р4 там 1130/1150 тактов на операцию (у Рentium ММХ - 105/103)...

А по FMUL и FADD результаты от точности не зависят вообще никак...

Tod Schwarzkaiser
А ты уверен что у тебя там исключения возникают? Хотя б и замаскированные. Вообще же fdiv [практически] не перекрывается, так что зависимые или нет - пофиг.

Не факт что этот код на современных CPU работает так как должен.
Распаралеливание может привести к тому что rdtsc будет выполнена _раньше_ чем завершен цикл. Я когда писал модуль подсчета тактов для увеличения точности создавал в памяти сегмент размером ~40kb и забивал его нужными инструкциями, получается линейный код который хочешь-нехочешь а придется выполнить, последняя команда возврат туда куда нам нужно. Попробуй, в этом случае точно никакие издержки цикла и суперскалярность мешать не будут.

KaYot достаточно делать это в потоке, который четко закрепленн за определенным процессором с помощью SetThreadAffinityMask.

результаты сильно скачут у пня? см. цикл статей на f-center про внутренню микроархитектуру П4, в частности:
http://www.fcenter.ru/cgi-bin/sitemanag ... urlid=4577
это скорость может добить окончательно

Daemon
Я не про многопоточность. Даже в одном потоке суперскалярный CPU может изменить последовательность выполнения команд, естественно на разных камнях алгоритмы перекомпиляции и исполнения 'наперед' разные.

KaYot но мы же не на VLIW'ах работаем

Daemon
Разница только в названии.