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

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

Страницы: 13 4 5 68 Следующая »
#45
22:38, 7 окт. 2010

cNoNim
> ну согласись не красиво костыли вырезать если они вовсе не костыли а специфика реализации
если до этого говорится, что не должно быть разницы на каком процессоре вызывать функцию, но разница есть из-за багов в BIOS и HAL, то следующие рекомендации по лечению, это ни что иное, как костыль

> Заметь ни о каком путешествии в прошлое речи нет...
я нигде и не писал, что эта ссылка описывает баг с путешествием в прошлое, правда?
его я наблюдал сам лично, а то, что по ссылке, не наблюдал, но верю

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


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

Executor
> Забейте на QPF, давайте по теме про QPC и разные ядра...
Я немного сбился с темы )
так вот...
а в чем таки глобальная проблема юзать QPC в одном главном потоке?
я таки этого и не пойму?
Update игры все равно происходит в одном потоке, дальше в процессе Update ты уже можешь там запустить паралельно какую либо задачу и тд. и тп. при этом тебе ведь не нужен будет там QPC нужно будет elapsed time, ну так посчитай его один раз и передавай в каждый паралельный поток в качестве параметра, или я чего то не понимаю?
пускать QPC в отдельном потоке и тем более городить костыли вроде слипа или синхронизации с этим потоком вообще бред, кто то с этим не согласен?
Вот даже допустим такая задача...
есть основной поток в нем юзается QPC и тд и тп...
тут нам понадобилось запустить второй поток допустим на 5 секунд соотвтетственно нам надо как то отсчитать 5 секунд и завершить второй поток
мы можем пойти двумя путями первый бредовый, но как мне кажется все начали бы городить нечто вроде него
1) запускаем второй поток и синхронизуем его с основным с помощью флага при этом в основном потоке отсчитываем 5 секунд и по прошествии сбрасываем флаг во втором потоке каждый раз проверяем этот флаг и если он сброшен прерывываем выполнение,
как то так, согласитесь каждый бы начал городить нечто подобное, не так ли?

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

я бы сделал все по другому...
2) у нас есть основной поток нам надо запустить поток на 5 секунд
ну так передайте эти 5 секунд во второй поток один раз при создании потока
во втором потоке опрасите QPF и юзайте спокойно QPC заюзав SetThreadAffinityMask...
теперь мы в потоке можем сами проанализировать предоставленное нам время, и по его истечению спокойно завершить выполнение,
если у нас поток выполняет несколько циклов мы може проанализировать время которое требуется потоку на выполнения цикла и если остается меньше времени тупо не выполнять очередную ветвь слипаем поток на оставшееся время и спокойно завершаем поток...
PROFIT, не ?

#47
22:48, 7 окт. 2010

arabesc
> но зачем использовать QPC с кучей костылей, когда можно просто использовать
> timeGetTime?вам недостаточно разрешения в миллисекунду? если так, вопросов
> нет...
да затем, что костыли эти дело прошлого и я думаю чем дальше тем меньше проблем описываемых тобой будет, к примеру в #40 ты описываешь баг который свойственен уже давольно таки устаревышим системам

#48
22:49, 7 окт. 2010

Executor
А http://www.opengl.org/registry/specs/ARB/timer_query.txt не использовал случаем?
Ну это OpenGL специфик да, но вдруг :)

#49
22:52, 7 окт. 2010

cNoNim
Поток не привязан к процессору. Он постоянно перепрыгивает, в произвольные моменты времени, с одного процессора на другой. Нельзя даже узнать, на каком процессоре мы сейчас выполняемся.

Расшифруй пожалуйста фразу: "передавай в параллельный поток в качестве параметра". Что это за параметры потоков такие?

#50
22:54, 7 окт. 2010

Zab
ну блин...
> Поток не привязан к процессору. Он постоянно перепрыгивает, в произвольные
> моменты времени, с одного процессора на другой. Нельзя даже узнать, на каком
> процессоре мы сейчас выполняемся.
SetThreadAffinityMask - тебе о чем нибудь говорит?

> Что это за параметры потоков такие?
т.е. ты ни когда ни какие параметры в потоки не передавал, я правильно понимаю,
и внутри потока от куданить взять значение ну ни как нельзя, так? мы точно об одних и тех же потоках говорим?

#51
22:57, 7 окт. 2010

Zab
нет желания лезть в дебри
вот почитай вот этот вброс
о чем это там говорится?
http://msdn.microsoft.com/ru-ru/library/6x4c42hc.aspx
а также (необязательно) передает объект с данными, используемыми методом в потоке.

PS: .Net, потому что есть переведенный на русский MSDN

#52
23:00, 7 окт. 2010

cNoNim
т.е. ты предлагаешь всем потокам явно назначить процессоры? Системе от этого не поплохеет? Мы же понятия не имеем, насколько загружены эти процессоры, а кто простаивает. И совсем хреново будет, если еще какие-нибудь параллельные программы пользуются тем же приемом.

#53
23:02, 7 окт. 2010

На каждое возможное действие потоки обычно не плодят. Их очень редко запускают, выполняют они большую группу действий, живут долго, почти бесконечно. Передача параметров производится только при старте. Это не представляет интереса.

#54
23:07, 7 окт. 2010

arabesc
> как отразится? timeGetTime других процессов станет возвращать более точные значения

А если другие процессы ухудшат точность? Помоему плохо зависеть от других приложений...

cNoNim
> а в чем таки глобальная проблема юзать QPC в одном главном потоке?

В том, что его значение будет зависеть от того, с какого ядра возьмётся, то бишь от звёзд на небе...

#55
23:09, 7 окт. 2010

В Windows разве нет какого нибудь GetTime с милли/микросекундной точностью? выдающее глобальное время а не тики каждого ядра.

#56
23:11, 7 окт. 2010

KpeHDeJIb
Не, не юзал... :)

Zab
+1

#57
23:13, 7 окт. 2010

Zab
> Передача параметров производится только при старте. Это не представляет
> интереса.
передавать параметры можно милионом способов, я лишь говорю что нужно как можно меньше синхронизаций и блокировок всяких.
Zab
> т.е. ты предлагаешь всем потокам явно назначить процессоры?
я предлагаю юзать QPC лишь в главном потоке, во всех остальных нам нужно только elapsed time при чем не совсем понятно, зачем он там если поток вообще паралельно выполняется и ни как с основным не связан, вот допустим у нас загрузка ресурсов в паралельном потоке, зачем там QPC? или elapsed time? нам надо просто запустить поток, и переодически узнавать не закончился ли он... а зачем там QPC?

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

теперь давай посмотрим на

DWORD_PTR WINAPI SetThreadAffinityMask(
  __in  HANDLE hThread,
  __in  DWORD_PTR dwThreadAffinityMask
);

Thread affinity forces a thread to run on a specific subset of processors. Setting thread affinity should generally be avoided, because it can interfere with the scheduler's ability to schedule threads effectively across processors. This can decrease the performance gains produced by parallel processing. An appropriate use of thread affinity is testing each processor.
The system represents affinity with a bitmask called a processor affinity mask. The affinity mask is the size of the maximum number of processors in the system, with bits set to identify a subset of processors. Initially, the system determines the subset of processors in the mask.
You can obtain the current thread affinity for all threads of the process by calling the GetProcessAffinityMask function. Use the SetProcessAffinityMask function to specify thread affinity for all threads of the process. To set the thread affinity for a single thread, use the SetThreadAffinityMask function. The thread affinity must be a subset of the process affinity.
On systems with more than 64 processors, the affinity mask initially represents processors in a single processor group. However, thread affinity can be set to a processor in a different group, which alters the affinity mask for the process. For more information, see Processor Groups.

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

#58
23:14, 7 окт. 2010

Executor
> В том, что его значение будет зависеть от того, с какого ядра возьмётся, то
> бишь от звёзд на небе...
так задай ядро, в чем проблема я все равно не пойму???

#59
23:16, 7 окт. 2010

Executor
> А если другие процессы ухудшат точность? Помоему плохо зависеть от других приложений...
это невозможно при корректной работе программ
система гарантирует наивысшую точность, запрошенную через timeBeginPeriod, до тех пор, пока не будет вызван соответствующий timeEndPeriod

Страницы: 13 4 5 68 Следующая »
ПрограммированиеФорумОбщее

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