Узнать процессорное время из MS-DOS приложения

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

 

OioVologda
Пример из MSDN

Функция clock собственно вызывает GetTickCount.

 

OioVologda

Точность измерения - да, но что ты ими намеряешь, если квант планировщика значительно больше?

 

Nouzui
Я конечно понимаю, что винде, по ее природе трудно обеспечить хорошую точность, но судя по самой используемой структуре у меня возникает чувство, что планировщик увеличивает ее простым ADD [стр-ра], 1 после каждых 100 нс. выполнения (возможно частота вызова планировщика).

crypto
Спасибо за код.

 

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

 

мда.. ну ты и сказанул ))

 

OioVologda
Хз что делает планировщик, а вот функция GetTickCount выглядит вот так (кто-то здесь уже этот код приводил):

Код (Text):

1. mov edx, 0x7ffe0000
2. mov eax, [edx]
3. mul dword ptr [edx+4]
4. shrd eax, edx, 24

 

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

 

crypto
Хорошая идея.
Я подумаю, но опять же много возни, если вдруг надо будет вносить изменения в код. А для того что бы автоматизировать процесс измрения, нужно будет прикуручивать дизассемблер...
Хотя, в общем то - это вообще идеальный вариант решения.

 

OioVologda

Точность должна быть достаточной для планирования. Ты же не думаешь, что ОС это некое надпроцессорное создание, которое может в любой момент посмотреть на свои суперточные часы. ОС существует не для того чтобы вести счет точного времени "после каждых 100 нс" (?!!), а для того чтобы обеспечивать работу приложений. Поэтому чтобы не пожирать попусту процессорное время считывание производится только по необходимости - при прерываниях системного таймера, переключении потоков или по запросу QueryPerformanceCounter. А вот GetTickCount\GetSystemTime просто выдают последнее из ранее считанных значений с дискретом (интервалом неопределенности) порядка 16 мс. Попробуй с помощью GetTickCount мерять короткие интервалы - получишь либо 0 либо значение кратное ~16 мс

 

crypto
Я его приводил в теме про SpeedGear. Все значения, возвращаемые с якобы 100 нс точностью, на самом деле обновляются один раз в 15 миллисекунд (10 миллисекунд на некоторых системах). Так что для измерения с 1 мс точностью они не подходят. Единственные оставшиеся кандидаты - QueryPerformanceCounter и rdtsc, но они тоже не подходят, потому что тикают независимо от того, выполняется нужный процесс или нет. Так что, имхо, задача не имеет простого решения. Винда ведь не система реального времени.

leo
Обогнал

 

а еще проще взять какой-нибудь существующий, не могу, правда, подсказать, какой..
кроме того, как эти профилеры проверяют время выполнения инструкции? по таблице? сейчас это не актуально, все зависит от очень многих факторов, вроде последних испролнявшихся команд (кэш результатов), наличия данных в кэше ОЗУ, иеханизма предвыборки итд..
если профилер проверяет время по системным часам, то нужно учесть, что частота процессора сейчас во много раз превосходит разрешение RTC - реультаты будут неверными, тем более, если метод действително такой, то досовские проги точно не рассчитывали, что между замерами времени их может прервать планировщик или прерывание, посколку cli под форточками выполнится, но не даст нужного эффекта..

 

никогда этим не занимался, но где-то так все себе и представлял.. )

 

Однако у этого варианта есть недостаток. Для того чтобы точно отследить все переходы и т.д. придется организовывать эмуляцию выполнения программы, а это, имхо не самый удачный вариант...

 

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

 

crypto, OioVologda

Эко куда вас понесло А не проще ли и точнее в task manager'е установить процессу приоритет реального времени ?

Скорее это просто здравая логика измерений - точность пропорциональна величине интервала. На малых интервалах винда не вмешивается и можно получить точность в несколько единиц-десятков тиков rdtsc. А для секундных интервалов вполне хватает и десятков-сотен миллисекунд

 

leo
Думаешь такой вариант прокатит?

 

leo
Досовская прога с приоритетом реального времени завесит все нафик, если сама повиснет

 

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

 

crypto
А разве паскаль сгенерирует мало коду?
А как быть с циклами? А если на входе случайные данные?

В таком случае единственный вариант - интерпретатор \ виртуальная машина (как Emu 8086)