Время исполнения кода.

Здрасти.
Есть участок кода. NT, планирование включено, юзермод. Нужно определить реальное время исполнения кода, без учёта квантования и затрат времени на диспатч ISR(не просто дельта тэ).

 

Все овощи похоже- весь васм не может решить такую задачу..
ГПЕ вам в помощь

 

Сходу:
Во-первых ВРЕМЯ - в кампутерах это понятие относительное, зависит от архитектуры проца и частоты (может имелось ввиду сравнение двух и более участков кода?)
Имхо, на НТ точно измерить - никак, нужно слабать свою ось, котрая только замеряет время кода и всё, и то будет различное в зависимости от настроек БИОС.

 

VTune чем не устраивает ?

Можно поюзать rdtsc.

Если нужно точнее то загрузочная дискета с своим загрузчиком который грузит твой кусок кода (без winapi) естественно.

А суперточно невозможно считать в многозадачной среде с планировщиком (всегда погрешность будет высока).

Особенно учитывая что разные процы с разным механизмом кеширования и пр. факторами типа паралельного исполнения команд.

Неясно зачем такая точность в юзермоде ?

 

asmlamo
Способы есть, это очевидно. С планировщиком можно суперточно определить длительность кванта и время обработки прерывания. Так как эти значения не постоянны, то накопив определённую статистику можно ввести константу для поправки. Эта константа помноженная на длительность даст среднее реальное время исполнения кода.
Потоки свопятся. Квант потока это и есть время исполнения кода отведённое потоку. За это время поток прерывает свою работу для обработки хардварных ISR многократно. И это всю можно учесть и измерить, так как физика реальна.
Вот интересен способ такого замера. Думаю тут большинсву это интересно.

Треш.
Вы знаете что значит вопрос тс. Если вам сказать нечего, то молчите. Есть иные форумы, где данный вопрос приемлим. Хотя признаю, что это один из лучших форумов в сети, не смотря на фильтрацию

 

artkar
Время понятие абсолютное.

 

gaeprust

Будь это форум по физике, я бы сказал: "Эх... щас начнётся".

Что же по теме... я почти уверен, что пожалею об этом, но почему "не просто дельта тэ"? По мне, так как раз "дельта тэ" здесь и подходит. Только "тэ" брать надо из поля UserTime структуры KERNEL_USER_TIMES, возвращённой вызовом ZwQueryInformationThread с первым инфоклассом.

 

l_inc
За секунду поток свопится при деволтном приоритете ~100%200 раз в секунду. Прерываний за время, отведённое потоку происходит несколько тысяч за секунду. Могу привести вам точные данные(например за одну инстуркцию dTSC ~ 70 на моём камне etc).
Важно реальное время исполнеия. Иначе при запрете прерываний или планирования вы не сможите вычислить реальную производительность. А так требуется только ввести поправку в виде константы, при неизменном приоритете потока и IRQL.

 

gaeprust
Под словом "свопится" понимается переключение потоков? Какое отношение это имеет к собственному времени потока?

 

Время отведённое потоку - один квант. Это несколько десятков или сотен mS. В течении этого времени процессор отдан потоку. Остальное время для потока холостое - поточный код не исполняется, так как процессор отдан другому потоку. Тоже происходит при обработке ISR - T-фрейм сохраняется и выполняется ISR, время исполнения этих диспетчеров не принадлежит потоку.

 

gaeprust

Именно поэтому "дельта тэ" потока и будет давать точное время исполнения кода потока без учёта времени всего остального.

 

Врямя исполнения кода = длительность обработки всех ISR за время всех квантов + длительность всех квантов, без учёта времени, затраченного на обработку ISR. Из одного кванта отнимается время обработки многих ISR.
Посему дельта тэ это абсолютное время. Если поток заморожен, дельта тэ не изменится, хотя поток ничего не исполняет.

 

Это фантастика. На разных системах оно будет разным ....

 

условия задачи я не понял, но из обсуждения сложилось впечатление, что требуется измерять время выполнения участка кода только если он целиком попадает в 1 квант. отвечу, как если бы я понял верно.

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

но может, я и не понял о чем тут. не вчитывался.

 

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

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

 

Dmitry_Milk
Вычислив поправочный коээфициент, можно будет определять время исполнения кода при изменении приоритета и не учитывать задержки, например зделав Sleep(200) - будет определено реальное время исполнения кода, а не время простоя.

asmlamo
Динамически ведь определить нужно, для той системы, на которой код будет исполняться.

qqwe
Простой потока при обработке ISR усложняет значительно задачу. У меня получились следующие результаты:

Код (Text):

1. $ ==>    0012FE2C    00001095
2. $+4      0012FE30    0000107F
3. $+8      0012FE34    00001194
4. $+C      0012FE38    000010F6
5. $+10     0012FE3C    000010AC
6. $+14     0012FE40    000010A4
7. $+18     0012FE44    000010D9
8. $+1C     0012FE48    0000109C
9. $+20     0012FE4C    000010E0
10. $+24     0012FE50    000011F5
11. $+28     0012FE54    00001167
12. $+2C     0012FE58    00001617
13. $+30     0012FE5C    00007466
14. $+34     0012FE60    000043A5
15. $+38     0012FE64    00007242
16. $+3C     0012FE68    0000676B
17. $+40     0012FE6C    00026A50
18. $+44     0012FE70    0000673E
19. $+48     0012FE74    00000069
20. $+4C     0012FE78    000065DE
21. $+50     0012FE7C    0000657C
22. $+54     0012FE80    00009948
23. $+58     0012FE84    00004BE9
24. $+5C     0012FE88    00000087
25. $+60     0012FE8C    00006504
26. $+64     0012FE90    00006879
27. $+68     0012FE94    0001986D
28. $+6C     0012FE98    00007088
29. $+70     0012FE9C    00011EE0
30. $+74     0012FEA0    00006574
31. $+78     0012FEA4    00005064
32. $+7C     0012FEA8    00004A88
33. $+80     0012FEAC    00006B67
34. $+84     0012FEB0    00005370
35. $+88     0012FEB4    0000431E
36. $+8C     0012FEB8    00007C8A
37. $+90     0012FEBC    00010B3F
38. $+94     0012FEC0    00005287
39. $+98     0012FEC4    000163EE
40. $+9C     0012FEC8    00008304
41. $+A0     0012FECC    000060E2
42. $+A4     0012FED0    000060C5
43. $+A8     0012FED4    000166AE
44. $+AC     0012FED8    00006EDC
45. $+B0     0012FEDC    000148EA
46. $+B4     0012FEE0    0000454A
47. $+B8     0012FEE4    0001BCB2
48. $+BC     0012FEE8    0000A0CF
49. $+C0     0012FEEC    00014EDD
50. $+C4     0012FEF0    00005A7F
51. $+C8     0012FEF4    00011795
52. $+CC     0012FEF8    00003DCA
53. $+D0     0012FEFC    00013ADA
54. $+D4     0012FF00    000061F8
55. $+D8     0012FF04    0000E1D2
56. $+DC     0012FF08    000138EC
57. $+E0     0012FF0C    00087C65
58. $+E4     0012FF10    0000AC4B
59. $+E8     0012FF14    0000DDB8
60. $+EC     0012FF18    00003E58
61. $+F0     0012FF1C    00011686
62. $+F4     0012FF20    0000DE8A
63. $+F8     0012FF24    0000188D
64. $+FC     0012FF28    00001932
65. $+100    0012FF2C    00001A0B

Это в стек заносится дельта тск:

Код (Text):

1. SET_INT_TRIGGER macro
2.     mov cx,RPL_MASK
3.     mov es,cx
4. endm
5.  
6.     mov ebx,64H
7. Next:  
8.     SET_INT_TRIGGER
9. @@:
10.     rdtsc   ; Возможно прерывание на этой инструкции и сброс триггера.
11.     mov cx,es
12.     test cx,cx
13.     jnz @b
14.     mov esi,eax
15.     mov edi,edx
16.     rdtsc
17.     sub edx,edi
18.     sub eax,esi
19.     adc edx,0
20.     push eax
21.     dec ebx
22.     jnz Next

По адресу 0x12FE74 значение мало - это было прерывание после установки триггера, которое пропустилось(для нескольких линейных инструкций dTSC ~ 0x70). 87C65 - это вероятно время простоя потока, произошёл свапконтекст. Его тоже можно измерить. Проблема в вычислении конечного значения - просто так по длительности не определить наверно, нужно учитывать есчо какоето отношение задержек.

 

А не проще ли данные замеры заранее провести в "грязном" виде (то есть включая прерывания и случайные переключения) на ВСЕХ уровнях приоритизации и не вычислять никаких коэффициентов?

 

Я тоже не понимаю смысл этого "чистого замера".

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

Зачем тогда вычислять "сферического коня в вакууме" ?

Практического смысла это не имеет.

Для точного "сферического расчета" нужно посчитать все команды и перемножить каждую на количество тактов для каждой команды.

 

asmlamo
Зная абсолютное время исполнения(тоесть реально отведённое потоку) можно вычислить любые другие задержки, введя поправочные коэффициэнты. Например есть у вас участок кода. Вы измерили время его исполнения как дельта тэ. Это значение никак не связано с приоритетом, IRQL, аффинитетом, IF etc. В моём случае тотже код, выполняемый на более высоком IRQL будет использовать времени больше на некоторую вычисляемую величину, она и исть поправка. Таким образом идеально вычисление реального времени, отданного потоку, а не виртуального, которое и есть дельта тэ.

 

ЗАЧЕМ???