У меня есть цель.
Узнать, за какое среднее количество тактов процессора выполняется та или иная инструкция.
Или точнее количество тактов, расходуемое на выполнение микрооперации (инструкции ещё самим процессором декодируются в микрооперации).

Команда чтения счетчика тактов работает под Windows на приложениях имеющих минимальный уровень привилегий, но она не помогает точно определить число тактов, потому что даже если имеется две команды между этими чтениями счетчика тактов - разница всегда равна 80.

Есть другой метод.
Составляем на ассемблере цикл, который содержит исследуемые инструкции и заставляем выполняться этот цикл много раз.
Для исключения сильного влияния команды перехода на начало цикла, делаем в цикле много таких инструкций.
Затем запускаем цикл во время выполнения программы и засекаем время выполнения всей этой бадяги.
Делим количество заранее известное выполнений цикла на количество секунд в которые выполнялся много кратно этот цикл. Получаем число циклов в секунду.
Делим реальную тактовую частоту процессора на это полученное "количество циклов в секунду".
Найдем количество тактов требующееся в среднем на прохождение цикла один раз.
Затем зная за сколько тактов выполняется в среднем другие команды присутствующие в этом цикле, находим количество тактов за которые в среднем выполняется инструкция.

Я таким методом хотел ещё год назад подсчитать количество тактов требуемое для инструкции сложения вещественных операндов. Тогда нашел, что операция сложения сопроцессором двух чисел с выталкиванием выполняется за один такт... Я все это время думал "как хорошо - команда сопроцессора для сложения выполняется за такое же время как и команда для целочисленного сложения". Но теперь оказалось, что ошибся.
Оказывается в среднем за четыре такта складываются вещественные числа !
Сам немогу до конца понять, как я смог так неточно определить сколько тактов требуется для вещественного сложения.
Я ещё думал, какое же хорошее устройство для выполнения вещественных операций.

А все дело заключалось в том, что процессору я задал простенький алгоритм.
Просто вся та бадяга строилась на том что одинаковая операция с одними и теми же ячейками памяти выполнялась много раз и содержимое исходных операндов не менялось - и в этом была вся сложность .
Я думал, что проц не учтёт то что последующие операции сложения можно не делать.
А оказывается процессор тогда оказался умнее.
Он каким-то особым образом "догадывается", что это все что я ему задаю - гонево !
Ну тогда и получилось, что я ошибся.
Недавно я экспериментировал над XMM-инструкциями процессора. Кто не знает - эти инструкции предназначены для одновременной обработки нескольких операндов (унарная операция) или пар операндов (бинарная операция). И над всеми этими операндами в XMM-регистрах одинаковые операции выполняются за такое же количество тактов, что и обычные команды требуют.
Так вот есть XMM-инструкция позволяющая складывать четыре пары вещественных чисел короткого формата (каждое число по 4 байта). И эта инструкция выполняется даже за меньшее число тактов, чем обычная инструкция для сложения вещественных чисел.
Ну я и думал - надо использовать в своем трехмерном движке именно инструкции SSE.
Ведь вещественными числами легче и точнее задать координаты точек. А складываются они за такое же время.
А ну давай я проверю на скорость выполнения XMM-инструкции !
Проверил, и смотрю что-то в четыре раза дольше
"Ну как так может быть, я же знаю что сложение выполняется разными сумматорами и за один такт. Или упакованные числа складываются не параллельно а каждое в одном такте. Ну если это так... то начерта тогда такое расширение АЛУ", - думал я.
Ну ладно, давай я ещё раз проверю на скорость выполнения команды обычного устройства процессора для вычилления вещественных чисел. Проверил - да ещё дольше ! Гад !
Значит то что я думал про скорость выполнения инструкций вещественных - то все неправда.
Я ещё проверял складывать XMM-регистры содержащие по два вещественных числа двойной точности (8 байт на число) в упакованном виде. Скорость та же что и по четыре пары чисел.
Нет, SSE-расширение действительно мощное !
Но просто для выполнения вещественных операций разработчикам процессора не удалось достич выполнения вещественного сложения меньше чем за четыре такта.
Я замерял ещё для операций вещественного и целочисленного делений скорость выполнения - не очень радует. Деление выполняется в несколько раз медленее сложения, умножения, вычитания.
А вещественное умножение выполняется за то же число тактов что и вещественное сложение или вычитание - это радует.
Я задумался над проблеммами разработчиков схемы процессора. Ну, конечно, не серьезно задумался, а так просто чтобы понять невозможность ускорить операцию деления.
Делит процессор наверное в столбик.
А этот столбик ведь он требует вычисления промежуточных операндов.
А следующая подоперация в делении, которая вычисляет следующий промежуточный операнд не выполнится без вычисления предидущего промежуточного операнда.
Так что действительно как не крути и не верти простую схему деления - не как не получится быстро разделить. А может есть другой путь и можно как-то усложнить схему, чтобы она делила за меньшее число тактов ?
Так что я понял, что операций деления в быстрых алгоритмах нужно избегать. А вместо них использовать логический сдвиг.

Кому интересно, могу сообщить. Операция вычисления тригонометрической функции
SIN(X) (на ассемблере - fsin) выполняется за 200 тактов.
Я ещё думал составлять собственную подпрограмму вычисления синусакоторая бы давала мне немножко меньшую точность, но выполнялась бы быстрее в пять раз.
И думал, неужели разработчики процессора такие глупые и не смогли ускорить в своих схемах выполнение тригонометрических функций.
Составил подпрограмму.
Примечательно то, что несмотря на то что она вычислает функцию через ряд Тейлора (Маклорена), в ней не используются операции деления вообще. Просто деление заменяется умножением на обратное число заранее известного значения.
Так я ещё тогда удивлялся - что-то моя функция дольше выполняется чем я предполагал.
Хотя стандартная команда для синуса выполняется на 20% дольше чем моя ассемблеровская функция.
А точность немножко моей функции ниже.
Да, я несколько теперь разочарован.

Это сообщение отредактировал(а) sgi1981 - 24.3.2006, 18:09

Здраствуйте.
У меня параллельные иследования. Вернее я на 8-ми разрядных микроконтролерах, которые не имеют опереций деления и умножения, реализовывал функции целочисленого деления и умножения 16 и 32 разрядных чисел. Все они по одному алгоритму работают : сдвиг+проверка+(сложение или вычитание). Занимают всегда одно количество циклов при операциях, 32 разрядные в два раза дольше.

Меня сейчас больше интересовать стал формат float 8 байтный стандарт. Не нахожу дельного описания самого формата. Хочется математическую библиотеку для микроконтролера с этими числами сделать.

Если имеете толковое описание формата плавающей запятой в электронном виде. Или подскажете книгу дельную. Отблагодарю. 

Hiehachi, курить IEEE 754 и все, что связано.
Например (англ.):
http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF
http://docs.sun.com/source/806-3568/ncg_goldberg.html 

Void,  Спасибо.
А на русском что нибудь - есть?  А то изучение затянется на год. Надо будет сначало мне формат английского языка  выучить. А потом эти исходники изучать.

А из советского недипломированого что-нибудь есть ?
Отблагодарю. 

 

Agner Fog

Assembly Language Page

How to optimize for the Pentium® microprocessors

Test programs for measuring clock cycles and performance monitoring 

sgi1981, как ты считаешь, что выполнится быстрее, просто умножить, к примеру, 2  на 3, или сделать сдвиг (2*2) и прибавить еденицу?
 

Это сообщение отредактировал(а) Exekutor - 18.4.2006, 13:59

sgi1981,  Большое спасибо. 

Добрый день.
Подскажите, существует ли таблица с числом тактов для инструкций процессора.
Нашел ссыль 
http://www.intel.ru/content/www/ru/ru/proc...er-manuals.html
Но то ли я слепой стал, но в этом справочнике число тактов в упор не вижу, только описание инструкций.