Помогите с подсчётом колличества тактов процессора

Здравствуйте. Я начинающий в этом деле. Раньше занимался на СИ а сейчас захотелось изучить низкоуровневое программирование.
Скажите пожалуйста, как можно подсчитать колличество тактов процессора в период исполнения определённого колличества комманд. Т.е. к примеру мне необходимо узнать сколько тактов производит процессор например в таком коде:

/Фактически здесь должен начинаться отсчёт/

Код (Text):

1. mov ah,09h
2. mov dx,offset msg
3. int 21h

/Здесь заканчиваться/

Заранее большое спасибо.

 

тема уже неоднократно поднималась - это сделать невозможно, особенно на современных процессорах.

 

ulcigor
Примерно можно через RDTSC, если время измерения достаточно велико. Однако есть много подводных камней. Например на Core 2 по RDTSC порой читается погода на марсе.
Притом, что код может запросто выполнятся разное количество тактов, в зависимости от состояния кешей и им подобных. В общем "измерить" действительно нельзя, можно только "оценить", причем для разных условий методика оценок разная.

 

А как тогда можно подсчитать время выполнение комманд. Пример тогда пусть будет тот же.
И ещё возник вопрос. Как можно вывести цифру на экран, не прибегая к WinAPI Т.е. используя стандартные средства Предположим мне нужно вывести в консоль число 30. Программа мне всегда пытается выдать ASCII код этого символа, а число никак не хочет... .

 

Ustus
А можно чуть подробней об этом и если можно немного полегче, без использования ненормативной лексики А то что то я вообще запутался. Я ведь в ассемблере только несколько дней кручусь. Так что мне ещё многое предстоит узнать...

 

MSoft
Почему невозможно? Возможно.

 

20$ и у тебя код перевода числа в строку. Код приватный, в паблике нет (алгоритм полностью разрабатывался, доводился и тестировался мною лично). Поэтому продажа строго в одни руки.

 

пример, если можно, который бы выдал четкое количество тактов, затраченное на те 3 инструкции (а если можно, то вообще для любого кода, а то 3 инструкции в дос - это как-то неинтересно)

 

Стандартыми для консоли является набор API предоставляемый ОС.
Ты можешь в ДОС выводить и в видео памить. Но это не относиться к стандартному вводу\выводу.
Чтобы вывести число тебе его надо преобразовать в строку. Это либы ручками через деление. Либы вызываем вин апи.
А после уже выводить.

 

MSoft
Вопервых хочу заметить что там вызов прерывания. Кода у меня пока нет. Но написать все можно.
Главу PERFORMANCE MONITORING у intel читали?

 

ulcigor
Ассемблер тут не при чем. Просто современные процессоры приличными словами не назовешь, ибо они есть out-of-order и superscalar. Вкратце это не расскажешь. Если интересно и дружишь с аглицким - читай Агнера Фога (Agner Fog) Здесь, например: http://www.agner.org/optimize/
Правда это для начинающего будет не слишком легко...
Но у Фога есть примеры, правда разобраться в них тоже не легко.
Поэтому выводы такие (если действительно интересуешься вопросами профайлинга/оптимизации).
Можно пользоваться инструкцией RDTSC - подробнее см. мануалы, вкратце - возвращает в EDX:EAX текущее значение 64-битного счетчика тактов, запускаемого на старте процессора и инкрементируемого теоретически каждый такт, практически - на процессорах NetBurst, например - на 8 каждые 8 тактов.
Но...
1. Современные x86 процессоры являются out-of-order - то есть могут выполнять инструкции не в том порядке, в котором они расположены в памяти, и superscalar - то есть могут параллельно выполнять несколько инструкций. Поэтому для увеличения точности используют так называемые сериализирующие команды, обычно это CPUID. то есть код выглядит примерно так:

Код (Text):

1.     xor     eax, eax
2.     cpuid
3.     rdtsc
4.     mov     dword ptr[_tmp], eax
5.     ; ... код, время выполнения которого измеряется.
6.     xor     eax, eax
7.     cpuid
8.     rdtsc
9.     sub     eax, dword ptr[_tmp]

в результате в EAX имеем нечто, имеющее отношение к количеству тактов
однако следует учитывать накладные расходы на само измерение - поэтому следует прогнать (желательно не один раз) приведеный выше пример без всякого кода и полученное значение (наименьшее, если несколько раз) запомнить, и потом вычитать из количества тактов.

2. Не на всех процессорах, как я уже упомянул, дискретность счетчика TSC равна единице. Например на Athlon и Athlon 64 таки равна. Если не ошибаюсь то же для Pentium II и III. На Pentium 4 и ему подобных дискретность равна 8 - то есть точнее, чем восемь тактов не померяешь. На Core 2 - похоже тоже. На Phenom - не знаю, не попадался еще в мои лапы. Также надо быть осторожным с этой инструкцией на Core 2, поскольку на них RDTSC работает корректно только при большой загрузке процессора, а количество тактов можно получить из PMC, но это уже большой гемморой (если интересно - у Фога есть пример. Из PMC вообще можно кучу всего интересного прочитать полезного при тонкой оптимизации).

3. Выполнение одного и того же кода может занимать разное количество времени, по причинам кешируемости кода и данных. Поэтому, если код выполняется несколько раз, обычно первое выполнение занимает значительно больше времени, чем все остальные. Поэтому код лучше выполнять несколько раз и изучать полученную пачку результатов.

4. Ну и наконец, на закуску - самое главное. Разные процессоры выполняют код абсолютно по-разному. Пэтому результаты, полученные, например на Pentium 4, как правило имеют мало общего с результатами тех же измерений на Pentium III, Athlon 64 или Core 2. Да что там! Даже Pentium 4 бывают разных видов! Так что следует иметь ввиду, что.

5. И еще то что, к процессору отношения не имеет. Если код работает с периферией, то тут уже такты мерить бесполезно. А int 21h именно этим и занимается, так надо иметь ввиду, что процессору возможно придется ждать другого железа.

 

Ustus

Это для прямых измерений.
А вот если загнать в цикл, а после и поделить на число циклов, то можно и с точностью до такта померить.
На моем пентиуме 4 дискретность 4. Правда в цикле удивительным оброзом счетчик начинает выдовать числа не только кратные 4, но и двум.

Можно отключить динамическое изменение частоты.

 

Pavia, с точностью до такта ты может и померишь какой-нить add/mult оперирующий регистрами. Как только у тебя mov из/в память - труба - первый проход будет измерять работу шины, а последующие систем cache-a. В результате вразумительных результатов не будет.

ulcigor, IMHO не надо парить моск - просто возьми Intel VTune и посмотри время и такты для конкретного участка.

P.S. про то как RAM/caches работают (9 частей):
http://lwn.net/Articles/250967/
http://lwn.net/Articles/252125/
http://lwn.net/Articles/253361/
http://lwn.net/Articles/254445/
....

 

команды..
AAA
AAD
AAS
AAM
или
DAA
DAS
должны решить твою проблему.

 

s0larian
И что с того? Вразумительные будут если мы будем знать что мерим. Вернее что хотим померить.

 

как раз RDTSC работает корректно всегда )) (разумеется с поправкой на дискретность и возможность внеочередного исполнения) а если частота процессора меняется из-за его слабой загруженности, то на производительности алгоритма в тактах это не отражается совсем и никак а абсолютное время выполения кода собственно при тестированиях алгоритма совершенно не принципиально оно может пригодится только при замере частоты, но это совсем другая тема из другого топика . Другое дело нестабильность результатов измерения связанная с особенностями работы камешков - но это не погрешность измерения, а именно фичи современных процессоров

Гы-Гы )

 

ответ:

 

Хм.. а ведь на 486-ых системах некоторые проги (как например DrHARD)умели черезвычайно корректно замерять скорость проца (а следовательно и тактов тестового кода).
зы
Вспомнил тут его для теста DOSBOX-а
зыы
http://www.google.com/search?rls=ru&q=drhard+dos

 

bugaga, не дашь ссылочку?

 

как хорошо... а с более древнененькой версией (нагугленой и похаченой добрыми пиплами от $) удалось затестить любимый еще дедушкой ленаном эмулятор NTVDM..
("новые" не осиливали стартануть)

И господа я просто ошеломлён точностью результатов теста 1Gh P-III (разогнаного до 1.1Ghz)!1

да.. умели немцы под DOS кодить.. эх
14-88!!1