Как отмерить кол-во тактов процессора, которые потребовались на выполнение функции или блока кода?
Можно конкретно под VS

Ну тут ещё под будет погрешность в кол-во тиков, которые занимают вот эти команды:



Можешь отдельно посчитать за сколько тиков они выполняются и искусственно отнимать это значение.

Это сообщение отредактировал(а) W4FhLF - 29.4.2007, 09:11

конкретно на ассемблере

в WinAPI есть по-моему функции
QueryPerformanceCounter(), GetTicksCount()

Добавлено через 1 минуту и 24 секунды
W4FhLF, 
зачем так сложно?

MAKCim, что именно тебе показалось сложным? rdtsc читает 64х разрядный счётчик из MSR10h и возвращает его в edx:eax, поэтому если между вызовами rdtsc проходит больше FFFFFFFFh тиков("тактов"), твой код работает неправильно. 

Это сообщение отредактировал(а) W4FhLF - 29.4.2007, 09:24

rdtsc и QueryPerformanceCounter() - это одно и то же. Одна проблема у них, не считают они время ядра, обе возвращают только время вне ядра(пользовательское). Чтобы посчитать фактическое время выполнения любого кода, нужно использовать функцию GetTicksCount, но она вернет сразу количество милисекунд, т.е., чтобы перевести в тики, нужно получить текущую частоту перфоманс-счетчика(QueryPerformanceFrequency/1000) и умножить на неё, полученное время, и то, это будет не точным значением, но позволит замерить относительную производительность. Частоту делим на 1000, чтобы получить число тиков в милисекунду.

Добавлено через 9 минут и 5 секунд
кстати, если кто-то сомневается, вызовите Sleep на пару секунд внутри блока замера. При слипе происходит переключение задач, все время, которое уходит на слип - это время работы ядра, а не программы, оно учтено не будет. Это простой пример. В основе любой программы время ядра распределено по-разному, поэтому мерить его необходимо тоже.

GremlinProg, что за бред ты несёшь? Ботай умные книги и впредь не неси такой ахинеи. 

Во первых, за бред ты уже получил минус, во вторых, ближе к сути.

GremlinProg, хаха... Парень, ну если ты так в себе самоуверен, хотя не понимаешь элементарных вещей, то я даже не знаю с чего начать... В каждом твоём утверждении есть ошибки, причём настолько глупые, что зная ты то, что знаю, посмеялся бы над ними вместе со мной. Я думаю рейтинг мой тебе лучше исправить, а сообщение своё удалить, автора темы оно только запутает и никакой пользы не принесёт, в личку я дам тебе информацию и некоторые объяснения, ты всё сразу поймёшь. Или я могу в этой теме легко доказать твою дисскуссионную несостоятельность, только потом без обид. Что выбираешь? 

Это сообщение отредактировал(а) W4FhLF - 29.4.2007, 11:37

Ты уж поверь мне, я проверил сей факт на реальных задачах, а не на высказываниях, подобных твоим, так что менять я ни чего не собираюсь.

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

Это сообщение отредактировал(а) Tectoder - 29.4.2007, 11:46

ты крайне не прав
для начала бы посмотрел, что такое Time Stamp Counter, и не говорил глупостей
изменение значения этого счетчика вообще говоря не зависит от CPL (user mode, kernel mode)
процессор увеличивает значение этого счетчика при каждом clock cycle

Добавлено через 2 минуты и 43 секунды
W4FhLF, 
ну да, все верно
просто для небольших фрагментов кода я не думаю, что количество циклов системных часов будет больше 0xFFFFFFFF 

GremlinProg, ну тогда запасайся терпением парень

Ну во-первых, если бы ты знал архитектуру процессора хотя бы на среднем уровне, то был бы в курсе, что rdtsc считывает значение одного из MSR регистров процессора(под номером 10h), этот регистр есть ни что иное, как внутрипроцессорный счётчик, который инкрементируется самим процессором, это целиком и полностью внутрипроцессорный механизм. На WinXP и выше(вроде даже на Win2k, но на память сказать не могу) QueryPerformanceCounter использует HPIT таймер, если он аппратано поддерживает, в противном случае используется PM таймер. Оба таймера располагаются на материнской плате. 
Оба эти механизма реализованы аппаратно и на этом уровне абсолютно всё равно на каком кольце привелегий выполняется код, счётчик в процессоре будет инкрементироваться, а таймер на мат.плате генерировать прерывания. 

Сможешь опровергнуть то, что я написал выше - будем вести беседу дальше. 

Хорошо, спорить не буду, сейчас не могу повторить свой прошлый эксперимент, работаю в другом проекте. Минус не исправлю, просто потому, что было оскорбление. Но поставлю плюс, если мои слова не подтвердятся. Скажу лишь, что замеры производились при разреженном по потокам рисовании в дибы, каждый отдельный диб - это слой конечного образа, которые при рисовании собирались в один, путем прозрачного наложения, вычислений было много, каждый поток реализовывал свой метод, каждый поток имел свою нагрузку, тратил различное время. Замеры вычилялись перфоменсом и тиком. При больших нагрузках перфоменс считал только время потока, без учета простоя при конкуренции, тик считал све стабильно и правильно.

Tectoder, 

это уже реализовано на уровне архитектуры (Performance Monitoring (см. IA-32 System Programming Manual))

Добавлено через 2 минуты и 43 секунды

что это?
знаю APIC таймер, внешний 8252 совместимый таймер, а о таком не слышал

Где было оскробление? Где? Покажи! Я лишь констатировал факт. Твоё незнание архитектуры системы и процессора - это твоя проблема, а не моя, вот и разбирайся в ней сам, а не метай стрелки. А если будут вопросы - создавай тему, помогу, чем смогу. В пределах данного топика твоего сообщение смотрелось бредово, потому, что твои рассуждения неверный и в любом случае ни GetTickCount, ни QueryPerformanceCounter не дают возможность !!!ИЗМЕРИТЬ КОЛ-ВО ТАКТОВ!!!!, именно это было нужно автору и именно rdtsc с некоторой степенью точности решает эту проблему!

Добавлено через 1 минуту и 43 секунды


Пардон, HPET(High Precision Event Timers).

http://en.wikipedia.org/wiki/High_Precision_Event_Timer