Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[Win32] QueryPerformanceCounter & GetLocalTime 16.10.08 06:29
Автор: void <Grebnev Valery> Статус: Elderman
|
работают приблизительно с одной и той же скоростью на XP и Vista (~1.5 mcs). Причём на Vista GetLocalTime даже быстрее чем QueryPerformanceCounter.
Почему? GetLocalTime должна бы работать в разы медленнее.
|
|
Опровергая себя... 20.10.08 00:57
Автор: void <Grebnev Valery> Статус: Elderman
|
> Почему? GetLocalTime должна бы работать в разы медленнее.
Какая глупость! Достаточно было сделать:
while(true)
{
//::QueryPerformanceCounter(&cnt1);
::GetLocalTime(&tm);
}
---
и посмотреть загрузку kernel CPU/user CPU. Затем, выполнить
while(true)
{
::QueryPerformanceCounter(&cnt1);
//::GetLocalTime(&tm);
}
---
и посмотреть загрузку kernel CPU/user CPU. Как говориться не уверен - не обгоняи и не задавай глупых вопросов ;)
|
|
[Win32] А почему GetLocalTime должна работать медленнее? 16.10.08 07:58
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 16.10.08 07:58 Количество правок: 1
|
|
Даже удивительно, что так долго они работают, поскольку вроде как структуры данных этих переменных обновляются ядром по прерываниям железа, но лежат они в разделяемой памяти, которая read-only для пользовательских процессов, и основное, на что тратится время при чтении -- на примитивы синхронизации.
|
| |
Да, ты прав. Я проверил. Если читать SystemTime,... 18.10.08 06:16
Автор: void <Grebnev Valery> Статус: Elderman
|
> Даже удивительно, что так долго они работают, поскольку
> вроде как структуры данных этих переменных обновляются
> ядром по прерываниям железа, но лежат они в разделяемой
> памяти, которая read-only для пользовательских процессов, и
> основное, на что тратится время при чтении -- на примитивы
> синхронизации.
Да, ты прав. Я проверил. Если читать SystemTime, InterruptTime KUSER_SHARED_DATA по адресу 0x7FFE0000 (или 0xffdf0000 kernel mode), аналогично тому как это делают KiQueryInterruptTime, KiQuerySystemTime, например, при помощи пары вызовов InitTime(void)/NT_GetKernelTime(void) из
документа http://research.microsoft.com/invisible/src/base/md/i386/sim/_glue.c.htm,
то получим приблизительно тоже время, что и ::GetSystemTime().
Так что похоже, что никакой синхронизации (и примитивов синхронизации) там нет - ::GetSystemTime() похоже тупо читает KUSER_SHARED_DATA.
|
| | |
Ну мож и нет примитивов, поскольку эти структуры обновляются... 18.10.08 08:02
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
Ну мож и нет примитивов, поскольку эти структуры обновляются ядром в прерываниях на высоких IRQ level'ах, + наверное LOCK-префиксы инструкций записи, то их никто не сможет читать во время записи, что и требуется.
|
| | | |
Может читать и читает. Там просто есть "примитивное... 18.10.08 21:55
Автор: void <Grebnev Valery> Статус: Elderman
|
> Ну мож и нет примитивов, поскольку эти структуры
> обновляются ядром в прерываниях на высоких IRQ level'ах, +
> наверное LOCK-префиксы инструкций записи, то их никто не
> сможет читать во время записи, что и требуется.
Может читать и читает. Там просто есть "примитивное использоване примитивов", поскольку ISR не может использовать никаких "lock", но должен обновить KSYSTEM_TIME как можно быстрее:
1) ISR (clock interrupt service routine) обновляет данные в строгом порядке:
вначале High2Time, затем LowPart, и в последнюю очередь High1Time.
2) Пользовательское приложение читает данные в обратном порядке:
High1Time, затем LowPart, и в последнюю очередь High2Time.
Синхронизация в том, что если High1Time != High2Time, то чтение повторяется снова (loop)
Например,
while (true) {
myTime.High1Part = USER_SHARED_DATA->SystemTime.High1Time;
myTime.LowPart = USER_SHARED_DATA->SystemTime.LowPart;
if (myTime.High1Part == USER_SHARED_DATA->SystemTime.High2Time)
{
break;
}
else
{
// _asm { pause } не уверен
}
}
---
|
|
|
подробно о проекте
Анализ криптографических сетевых...
