Войти
ПрограммированиеФорумОбщее

QueryPerformanceCounter и многоядерность (3 стр)

Страницы: 1 2 3 4 58 Следующая »
#30
20:47, 7 окт. 2010

ksacvet777
> хм , странно что я этого тут не прочёл (мож плохо смотрел)... потому напишу сам:

Я в курсе, что надо ещё юзать QPF, иначе как бы у меня таймер работал...
Тема не об этом...

cNoNim
> QueryPerfomanceFrequency может поменяться только после перезапуска системы

У процессора частота может меняться во время работы, особенно у современных процов, особенно у ноутбучных... Поэтому должен и QPF меняться...


#31
20:50, 7 окт. 2010

Мизраэль
> Если твой код не корректно себя ведёт из-за особенностей операционки, то наверное это проблемы кода :)

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

> Какое решение ты ждёшь? Сам ведь понимаешь, что при миграции с одного
> процессора на другой с таймером будут проблемы. Вариант, который ты показал в
> начале - вообще бред полный. Думай над архитектурой движка, чтобы можно было
> сразу на два ядра лечь, если тебя так волнует производительность.

Причём тут на сколько ядер лечь? Как связано это с таймером?
Задача проста, посадить таймер на одно ядро красиво и правильно, всё... Причём тут то, что у меня работает или не работает на других ядрах?

З.Ы. В дальнейшем то, что посчитаю не нужным буду косить... Пишите пожалуйста строго по теме...

#32
21:20, 7 окт. 2010

Executor
> "This function affects a global Windows setting."
> Поэтому в топку...
почему, поэтому?
ну да, глобально меняется точность таймера в большую сторону - это катастрофа?..

а городить для QPF/QPC отдельный поток и заморачиваться с его pause/resume, которые должны быть чаще, чем стандартный квант, иначе выигрыша перед timeGetTime особо нет, это нормально?

#33
21:40, 7 окт. 2010

Частота счетчика производительности не может изменяться пока система работает: "The frequency cannot change while the system is running." - так говорит МСДН. Если исходить из этого, получается, что счётчик производительности не является счётчиком тактов процессора. Иначе, частота счётчика менялась бы от степени нагрузки процессора, как и говорит товарищ Executor. И вместо SetProcessAffinityMask() используем SetThreadAffinityMask().

#34
21:43, 7 окт. 2010

Я немного не пойму, почему вы связываете QueryPerformanceFrequency с частотой процессора?
Мне что-то верится с трудом, что QueryPerformanceFrequency имеет прямую зависимость с частотой процессора, которая может
меняться в 3-4 раза на тех самых ноутбуках, при этом мелкософт особо не заботится о ее актуальности перед каждым обращением к QPC.

Retrieves the frequency of the high-resolution performance counter, if one exists. The frequency cannot change while the system is running.

В мелкософте наверное совсем идиоты...

Да я согласен, QPF может отличаться на разных процессорах, и может зависеть от температуры процессора, напряжения в сети и прочей лабуды, но так ли сильна эта зависимость? и на сколько большими могут быть изменения?
И еще? А ктонить достоверно может сказать как QPF работает?
А кто вам сказал, что ее значение не сохраняется один раз во время запуска системы и не изменяется до следующего запуска?
Ктонить вообще пробовал проследить за изменением частоты?
Вот простой синтетический тест )

#include <Windows.h>
#include <stdio.h>

int main(int argc, char *argv[], char **envv)
{
    LARGE_INTEGER cur, old;
    QueryPerformanceFrequency(&old);
    for(;;)
    {
        QueryPerformanceFrequency(&cur);
        if(cur.QuadPart != old.QuadPart)
        {
            printf("Frequency changed (old: %lld,\tnew: %lld)\n", old.QuadPart, cur.QuadPart);
        }
        old = cur;
        Sleep(0);
    }
    return 0;
}
Что мне надо сделать, чтоб сообщение вывелось на экран? у мну щас как раз тот самый ноутбук
UPD: блин долго печатал

#35
21:56, 7 окт. 2010

cNoNim
> Ктонить вообще пробовал проследить за изменением частоты?
Я замерил: максимальное и минимальное значение частоты в loop'е - одинаковы и не меняются.

#36
21:59, 7 окт. 2010

Алмаз
щас пускал, свой ноут в Сон и в Гибернацию, с запущенным тестом...
частота не изменилась полет нормальный, что мне еще можно сделать?

#37
22:02, 7 окт. 2010

на некоторых глючных системах значение QPC иногда прыгает в прошлое
года 2-3 назад мне попадался такой комп

#38
22:04, 7 окт. 2010

arabesc
надо сначала проверить не было ли там переключения потока на другой процессор, а то малоли, мож не система глючная а руки кривые?
QPC скорре всего тупо счетчик, как он может прыгнуть в прошлоее? в связи с каким физическим процессом?

#39
22:14, 7 окт. 2010

cNoNim
> надо сначала проверить не было ли там переключения потока на другой процессор
вполне могло быть
но руки кривые тут на более низком уровне, т.к.: "On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL)." и дольше про костыли

и ещё из "приятного" - Performance counter value may unexpectedly leap forward

#40
22:18, 7 окт. 2010

и ещё: Programs that use the QueryPerformanceCounter function may perform poorly in Windows Server 2000, in Windows Server 2003, and in Windows XP

#41
22:21, 7 окт. 2010

arabesc
> ну да, глобально меняется точность таймера в большую сторону - это катастрофа?..

Да, это ведь отразится на других приложениях, а это очень и очень плохо... Я не одобряю...

> а городить для QPF/QPC отдельный поток и заморачиваться с его pause/resume,
> которые должны быть чаще, чем стандартный квант, иначе выигрыша перед
> timeGetTime особо нет, это нормально?

Это лучше, чем вмешиваться в работу других приложений...

cNoNim
> Я немного не пойму, почему вы связываете QueryPerformanceFrequency с частотой процессора?

Потому что я ступил... :) Связи нет, ты прав...

Забейте на QPF, давайте по теме про QPC и разные ядра...

#42
22:22, 7 окт. 2010

cNoNim
На АМД процах глюк был с QPC, херню показывал, ну это баг ихней, фиксы были...

#43
22:29, 7 окт. 2010

arabesc

On a multiprocessor computer, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the basic input/output system (BIOS) or the hardware abstraction layer (HAL). To specify processor affinity for a thread, use the SetThreadAffinityMask function.

ну согласись не красиво костыли вырезать если они вовсе не костыли а специфика реализации.
Именно о этих выпрямители рук я и говорил в #38

дальше
arabesc
> Performance counter value may unexpectedly leap forward

The result that is returned by the QueryPerformanceCounter function may unexpectedly leap forward from time to time. This leap may represent several seconds.

Заметь ни о каком путешествии в прошлое речи нет... говорится как раз о путешествии в будущее
и это как раз следствие того, что QPC счетчик пускай в нем и могут быть какие либо аппаратные лаги которые между прочим фиксились обновлением драйвера
> Programs that use the QueryPerformanceCounter function may perform poorly in
> Windows Server 2000, in Windows Server 2003, and in Windows XP
и присущи только одному производителю процессоров?

при этом я лишь хочу одно сказать...
IMHO: скачки в перед не сильно критичны в GD при правильной реализации

#44
22:30, 7 окт. 2010

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

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

Страницы: 1 2 3 4 58 Следующая »
ПрограммированиеФорумОбщее

Тема в архиве.