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

Тема в разделе "WASM.A&O", создана пользователем gaeprust, 22 май 2011.

  1. gaeprust

    gaeprust New Member

    Публикаций:
    0
    Регистрация:
    2 май 2011
    Сообщения:
    188
    Здрасти.
    Есть участок кода. NT, планирование включено, юзермод. Нужно определить реальное время исполнения кода, без учёта квантования и затрат времени на диспатч ISR(не просто дельта тэ).
     
  2. TrashGen

    TrashGen ТрещГен

    Публикаций:
    0
    Регистрация:
    15 мар 2011
    Сообщения:
    1.173
    Адрес:
    подполье
    Все овощи похоже- весь васм не может решить такую задачу..
    ГПЕ вам в помощь
     
  3. artkar

    artkar New Member

    Публикаций:
    0
    Регистрация:
    17 авг 2005
    Сообщения:
    400
    Адрес:
    Russia
    Сходу:
    Во-первых ВРЕМЯ - в кампутерах это понятие относительное, зависит от архитектуры проца и частоты (может имелось ввиду сравнение двух и более участков кода?)
    Имхо, на НТ точно измерить - никак, нужно слабать свою ось, котрая только замеряет время кода и всё, и то будет различное в зависимости от настроек БИОС.
     
  4. asmlamo

    asmlamo Well-Known Member

    Публикаций:
    0
    Регистрация:
    18 май 2004
    Сообщения:
    1.729
    VTune чем не устраивает ?

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

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

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

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

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

    gaeprust New Member

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

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

    gaeprust New Member

    Публикаций:
    0
    Регистрация:
    2 май 2011
    Сообщения:
    188
    artkar
    Время понятие абсолютное.
     
  7. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    gaeprust
    Будь это форум по физике, я бы сказал: "Эх... щас начнётся".

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

    gaeprust New Member

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

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    gaeprust
    Под словом "свопится" понимается переключение потоков? Какое отношение это имеет к собственному времени потока?
     
  10. gaeprust

    gaeprust New Member

    Публикаций:
    0
    Регистрация:
    2 май 2011
    Сообщения:
    188
    Время отведённое потоку - один квант. Это несколько десятков или сотен mS. В течении этого времени процессор отдан потоку. Остальное время для потока холостое - поточный код не исполняется, так как процессор отдан другому потоку. Тоже происходит при обработке ISR - T-фрейм сохраняется и выполняется ISR, время исполнения этих диспетчеров не принадлежит потоку.
     
  11. l_inc

    l_inc New Member

    Публикаций:
    0
    Регистрация:
    29 сен 2005
    Сообщения:
    2.566
    gaeprust
    Именно поэтому "дельта тэ" потока и будет давать точное время исполнения кода потока без учёта времени всего остального.
     
  12. gaeprust

    gaeprust New Member

    Публикаций:
    0
    Регистрация:
    2 май 2011
    Сообщения:
    188
    Врямя исполнения кода = длительность обработки всех ISR за время всех квантов + длительность всех квантов, без учёта времени, затраченного на обработку ISR. Из одного кванта отнимается время обработки многих ISR.
    Посему дельта тэ это абсолютное время. Если поток заморожен, дельта тэ не изменится, хотя поток ничего не исполняет.
     
  13. asmlamo

    asmlamo Well-Known Member

    Публикаций:
    0
    Регистрация:
    18 май 2004
    Сообщения:
    1.729
    Это фантастика. На разных системах оно будет разным ....
     
  14. qqwe

    qqwe New Member

    Публикаций:
    0
    Регистрация:
    2 янв 2009
    Сообщения:
    2.914
    условия задачи я не понял, но из обсуждения сложилось впечатление, что требуется измерять время выполнения участка кода только если он целиком попадает в 1 квант. отвечу, как если бы я понял верно.

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

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

    Dmitry_Milk Member

    Публикаций:
    0
    Регистрация:
    20 ноя 2007
    Сообщения:
    535
    Возможно ли озвучить исходную задачу, в смысле ту, для которой потребовалось вот это непонятное измерение "чисто потребленного процессорного времени"?

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

    gaeprust New Member

    Публикаций:
    0
    Регистрация:
    2 май 2011
    Сообщения:
    188
    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 - это вероятно время простоя потока, произошёл свапконтекст. Его тоже можно измерить. Проблема в вычислении конечного значения - просто так по длительности не определить наверно, нужно учитывать есчо какоето отношение задержек.
     
  17. Dmitry_Milk

    Dmitry_Milk Member

    Публикаций:
    0
    Регистрация:
    20 ноя 2007
    Сообщения:
    535
    А не проще ли данные замеры заранее провести в "грязном" виде (то есть включая прерывания и случайные переключения) на ВСЕХ уровнях приоритизации и не вычислять никаких коэффициентов?
     
  18. asmlamo

    asmlamo Well-Known Member

    Публикаций:
    0
    Регистрация:
    18 май 2004
    Сообщения:
    1.729
    Я тоже не понимаю смысл этого "чистого замера".

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

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

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

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

    gaeprust New Member

    Публикаций:
    0
    Регистрация:
    2 май 2011
    Сообщения:
    188
    asmlamo
    Зная абсолютное время исполнения(тоесть реально отведённое потоку) можно вычислить любые другие задержки, введя поправочные коэффициэнты. Например есть у вас участок кода. Вы измерили время его исполнения как дельта тэ. Это значение никак не связано с приоритетом, IRQL, аффинитетом, IF etc. В моём случае тотже код, выполняемый на более высоком IRQL будет использовать времени больше на некоторую вычисляемую величину, она и исть поправка. Таким образом идеально вычисление реального времени, отданного потоку, а не виртуального, которое и есть дельта тэ.
     
  20. Dmitry_Milk

    Dmitry_Milk Member

    Публикаций:
    0
    Регистрация:
    20 ноя 2007
    Сообщения:
    535
    ЗАЧЕМ???