На новый год полностью обновил свой компьютер. Раньше был AMD486 120МГц. Теперь Celeron 2.5ГГц. Ну и решил посмотреть повышение производительности. Для вычислений с плавающей точкой (FSIN в цикле) скорость стала в 15 раз выше, что оказалось меньше, чем я ожидал. Поэтому написал программу, показывающую число тактов между двумя инструкциями RDTSC. В результате для кода:
...
rdtsc
mov ebx,eax
rdtsc
sub eax,ebx
...
получил 80 тактов !!! Кто-нибудь знает в чем причина такой проторможенности? Еще инструкция FSIN в некоторых случаях занимала до 1000 тактов. Это при том что в описании для 80486 процессора сказано, что эта инструкция самое многое занимает не более 300 тактов (или 400, но уж точно не 500). Что вы думаете насчет этого?

ты не пробовал почитать доки по оптимизации кода?

Я оптимизацией кода не занимался. Но неужели трудно дать ответ на вопрос от чего зависит число тактов. Я так понимаю в новых процессорах это число не должно быть гораздо большим чем в старых. Это как то ненормально. Я еще могу понять увеличение числа тактов на 20-30%, но не такое вопиющее. Да и инструкция RDTSC вроде простая чтоб занимать так много тактов.

В целом, стоит почитать Агнера Фога и других.
А кратко.
Начнём с того, что сама инструкция чтения счётчика занимает не меньше десяти тактов. Кроме того, она не подлежит параллельному выполнению. Далее, на загрузку инструкций требуется также время. А если она при этом ещё и не в кэше...
Кроме того, интеловцы в доке по использованию RDTSC советуют до него выполнят сериализующую инструкцию типа CPUID, да к тому же раза 3, прежде чем мерять что-то. И потом перед каждым RDTSC. Кроме того, не забывай, что винда есть ось многозадачная. Теоретически посреди твоего замера может включиться другой тред или процесс. А счётчик циклов - один на всех. Обычно для этого своему процессу ставят приоритет почти самый высокий.
И ещё. В своём примере ты обрабатываешь лишь нижние 32 бита счётчика, а он 64-битный. Теперь смотри:
2^32=4.294.967.296 такта, после которых нижние биты сбрасываются и переносят 1 в верхнее двойное слово.
На процессоре 400MHz такой сброс происходит каждые 11 секунд:
4.294.967.296/400.000.000=10,73741824 сек.
А у тебя 2.5GHz
4.294.967.296/2.500.000.000=1,7179869184 сек.
А если ты будешь считать с точностью 64 бита то даже на твоём проце полный оборот счётчика произойдёт лишь через 700 лет.

А более подробно разбираться в этом деле надо действительно с различных документаций. А так, объясняешь одно, а оно цепляется за другое, а у другого всплывают ещё различные тонкости. Если укажешь своё мыло, могу выслать PDF описаловку по использованию RDTSC от Интела с примерами (73Кб). Правда на английском.

pervy test vsegda tak ploh, normalnye znachenija pokazyvajutsja tolko s tretjego prohoda (testirovat' nuzno v cikle). Na mojom AthlonXP 2400 para RDTSC, 8 NOPov, i LOOP, trebujut v srednem 12 taktov, fsin 90 taktov.

Спасибо вам SolidCode и ydab за ответы. SolidCode вышли мне описание на мэйл: icebp@hotmail.ru В программе я использовал младшие 32 бита для того чтобы между RDTSC был минимум инструкций, а вероятность того, что программа будет запущена в момент сброса младших 32 бит исчезающе мала, поэтому EDX я не сохраняю. Программу я запускал из под чистого DOS и запрещал прерывания, поэтому между RDTSC перерывов быть не должно (вообще я всегда свои программы запускаю из под DOS во избежание разного рода коллизий, конечно за исключением тех случаев, когда я пишу WINDOWS программы). Как я понял ydab-а, так много тактов может быть из-за незаполненности кеша при первом проходе, а если сделать цикл, то кеш заполнится и тактов потребуется меньше.

В программе я использовал младшие 32 бита для того чтобы между RDTSC был минимум инструкций
В процессорах пентиум и выше следующий код подойдёт:
1.cpuid
2.rdtsc
3.mov ecx,eax
4.mov ebx,edx
5.rdtsc
6.sub eax,ecx
7.sbb edx,ebx
При этом инструкции 3 и 4 выполнятся параллельно, т.е. одновременно (см. Фога).
Как я понял ydab-а, так много тактов может быть из-за незаполненности кеша при первом проходе, а если сделать цикл, то кеш заполнится и тактов потребуется меньше.
Правильно. Тот PDF я сейчас вышлю. И там в официальной доке они советуют прежде выполнить 3 cpuid, а потом в цикле считать такты, чтобы получить среднее.

Icebp
rdtsc
mov ebx,eax
rdtsc
sub eax,ebx
...
получил 80 тактов !!!

Интел не гарантирует соответствие tsc тикам проца. Они гарантируют только монотонное возрастание счетчика.
Так что такты таким способом измерять нельзя :(

Kba3iM0go, так это ты серьезно что ли? У меня тогда вопрос: а на черта тогда нужна инструкция rdtsc если она такая кривая. И второй вопрос: как же тогда мерить такты? Они что, получается, остаются тайной покрытой мраком? Я так понимаю ты это на 1-ое апреля пошутил, не так ли?

Icebp
Kba3iM0go, так это ты серьезно что ли?
Конечно.

на черта тогда нужна инструкция rdtsc
Для сравнения производительности разных кусков кода (с)интел

как же тогда мерить такты?
а никак, похоже...

Я так понимаю ты это на 1-ое апреля пошутил, не так ли?
сегодня уже второе. я не шутил...

самому, блин, жаль :(

Народ, немного напрягает каждый раз читать одни и теже вопросы. Есть же поиск в конце концов.
Four-F давал там ссылку на профайлер, также была ссылка на топик на реверсинг.нет, который сейчас не работает (точнее, работает, но на другом урле и под паролем).
Вообщем, вот ссылка на мануал. Там правда есть один баг... если в кратце, то перед cpuid надо вставлять xor eax,eax.

Kba3iM0go
Интел не гарантирует соответствие tsc тикам проца. Они гарантируют только монотонное возрастание счетчика

Цитата из того же мануала...

...The Intel time-stamp counter is a 64-bit MSR that is incremented every clock cycle... To access this counter, programmers can use the RDTSC instruction...

Max
Цитата из того же мануала...

шото тут не то. надо разобраться...
завтра будет видно :)