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

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

Страницы: 1 2 37 8 Следующая »
#0
12:18, 7 окт. 2010

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

  SetProcessAffinityMask(GetCurrentProcess(), 1);
  QueryPerformanceCounter(count);
  SetProcessAffinityMask(GetCurrentProcess(), oldProcessAffinityMask);

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


#1
12:27, 7 окт. 2010

Executor
> Красиво ли так делать?
> Как можно иначе решить проблему?
> Мне тут предлагали засунуть таймер в отдельный поток, а потом посадить на одно
> из ядер... Но не знаю насколько удачная эта идея...

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

#2
12:27, 7 окт. 2010

Я в свое время от него анимацию интерполировал, на Core2Duo были ужасные глюки, он то торопился, то проглатывал... заменил его на GetTickCount...
А вообще его нужно в отдельном треде гонять. ( в данной ситуации )

#3
12:39, 7 окт. 2010

Я просто главный поток "сажу" на одно ядро. И в нем уже дергается время. Или тебе надо из разных потоков получать значения?

#4
12:42, 7 окт. 2010

Вообще похорошему надо не только counter каждый кадр получать, а наверное и частоту, ибо частота одного и того же ядра ведь может поменяться со временем...
Ок, значит засовываем таймер в отдельный тред...
Нам данные таймера нужны один раз в начале кадра, чем будет поток таймера заниматься до начала следующего кадра? Крутить в цикле и слипать до тех пор пока не понадобяться новые данные? Или же сделать евент как в сосденей теме? (На всякий случай говорю, что темы две не связаны, они про разные приложения совсем)

Andru
> Я просто главный поток "сажу" на одно ядро. И в нем уже дергается время.

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

#5
12:47, 7 окт. 2010

Executor
> Вообще похорошему надо не только counter каждый кадр получать, а наверное и
> частоту, ибо частота одного и того же ядра ведь может поменяться со временем...

Ну так создаешь тред, вешаешь на одно ядро, получаешь частоту и работаешь, все.

> Нам данные таймера нужны один раз в начале кадра, чем будет поток таймера
> заниматься до начала следующего кадра? Крутить в цикле и слипать до тех пор
> пока не понадобяться новые данные? Или же сделать евент как в сосденей теме?
> (На всякий случай говорю, что темы две не связаны, они про разные приложения
> совсем)

Ну ак, в потоке таймера Опрос / Слип / Опрос / Слип, я так сделал, т.е. просто обновление
значения текущего состояния таймера. А в главном потоке просто опрос этого состояния,
без опроса самого таймера.

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

На самом деле нет :) Или у тебя там специальные какие-то ухищрения? Например
графика у тебя явно на одно ядро завязана, а вот для подгрузки ресурсов скажем
второе ядро точно не нужно. Кстат ия такой способ тоже использую, сажаю прогу
на одно ядро сразу и все, особых проблем не замечено. Другое дело что этот
подход не самый "правильный", в отдельном треде все таки баще :)

#6
12:55, 7 окт. 2010

>> Другое дело что этот подход не самый "правильный", в отдельном треде все таки баще :)

Вариант "Опрос / Слип / Опрос / Слип" тоже как-то не сильно правильный ввиду погрешностей Sleep'а.

#7
12:57, 7 окт. 2010

Andru
> Вариант "Опрос / Слип / Опрос / Слип" тоже как-то не сильно правильный ввиду
> погрешностей Sleep'а.

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

#8
13:19, 7 окт. 2010

KpeHDeJIb
> Ну ак, в потоке таймера Опрос / Слип / Опрос / Слип, я так сделал, т.е. просто
> обновление значения текущего состояния таймера. А в главном потоке просто опрос этого
> состояния, без опроса самого таймера.

Ну то есть у тебя значение таймера берутся тогда, когда они не нужны... Разве это хорошо?

> На самом деле нет :)

У меня так... Разница в скорости 30-35%...
Я даже тему по этому поводу создавал както:
http://www.gamedev.ru/code/forum/?id=136707#m4

> Или у тебя там специальные какие-то ухищрения?

Нет, тупо один главный поток...

#9
13:21, 7 окт. 2010

Executor
> Ну то есть у тебя значение таймера берутся тогда, когда они не нужны... Разве это хорошо?
А что не так? Ну т.е. почему бы это было плохо? Опросить таймер не так уж проблематично.

ЗЫ. Должен же отдельный поток чем-то заниматься :D

PPS. Ну т.е. как по другому сделать номрально опрос таймера в этом потоке? Спросить и ждать
пока он продолжит поток, опросит таймер и вернет значение и потом снова остановит поток?

#10
13:44, 7 окт. 2010

KpeHDeJIb
> А что не так? Ну т.е. почему бы это было плохо? Опросить таймер не так уж проблематично.

Зачем тратить время на выполнение того, что не нужно?
Таймер тоже не бесплатный, а QPC наиболее тяжёлый из способов...

> PPS. Ну т.е. как по другому сделать номрально опрос таймера в этом потоке? Спросить и ждать
> пока он продолжит поток, опросит таймер и вернет значение и потом снова остановит поток?

Ага, у меня такая мысля была, после прочтения предыдущей моей темы...

#11
13:47, 7 окт. 2010

за что вы так timeGetTime не любите?

#12
13:48, 7 окт. 2010

Executor
> Таймер тоже не бесплатный, а QPC наиболее тяжёлый из способов...
Ну опрос таймера в отдельном потоке большую нагрузку не создаст вобщем-то.

#13
14:15, 7 окт. 2010

arabesc
> за что вы так timeGetTime не любите?

"The default precision of the timeGetTime function can be five milliseconds or more"
Наверное за это... :)
5 мс, куда к чёрту...
Учитывая, что на кадр уходит 10-15 мс помоему большая погрешность...

#14
14:18, 7 окт. 2010

KpeHDeJIb
>> Сомневаюсь что время рендера занимает время меньшее чем слип потока таймера.
Как-бы бывает и больше 60fps'ов. А Sleep как раз грешит в районе от 10 до 16мс. :)

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

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