Что хорошего в маске слияния нитей для текущей темы?

Question

Я пишу игровой движок, и мне нужен способ получить точное и точное значение «deltatime», из которого можно получить текущий FPS для отладки, а также ограничить частоту кадров (это важно для нашего проекта).

Выполнение небольшого исследования, я узнал, что один из лучших способов сделать это - использовать функцию QueryPerformanceCounter WinAPI. GetTicksCount должен использоваться для предотвращения forward counter leaps, но это само по себе не очень точно.

Теперь проблема с QueryPerformanceCounter заключается в том, что она, по-видимому, может возвращать значения, которые выглядели бы, если бы время искажалось (т. Е. Вызов может возвращать значение ранее по времени относительно другого вызова в прошлом). Это происходит только тогда, когда значение, полученное с помощью данного ядра процессора сравнивается со значением, полученным с другим ядром процессора, что приводит меня к основным вопросам, которые побудили меня сделать этот пост:

1. мая OS «перераспределить» нить в другое ядро, пока поток уже запущен, или поток выделяется для данного ядра, и это до тех пор, пока нить не умрет?
2. Если нить не может быть перераспределена (и это, по крайней мере, имеет для меня большой смысл), то почему это возможно для меня сделать что-то вроде SetThreadAffinityMask(GetCurrentThread(),mask)? Ogre3D делает это в своем Ogre::Timer class (Windows implementation), и я предполагаю, что во избежание повторного возвращения. Но для того, чтобы это было правдой, мне пришлось бы рассмотреть возможность того, что потоки будут перемещаться из одного ядра в другое произвольно ОС, что кажется мне довольно странным (не совсем понятно).

Я думаю, это было все, что я хотел знать. Благодарю.

Answer 1

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

Что касается таймера apis. timeGetTime предназначен для синхронизации мультимедиа, поэтому он немного точнее, чем GetTickCount.

QueryPerformanceCounter(). все еще ваше самое точное измерение. Microsoft говорит об этом.

На многопроцессорном компьютере не должно иметь значения, какой процессор вызывается.Тем не менее, вы можете получить разные результаты на разных процессорах из-за ошибок в базовой системе ввода/вывода (BIOS) или слоя абстракции аппаратного обеспечения (HAL). Чтобы указать сродство процессора к потоку, используйте функцию SetThreadAffinityMask.

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

Answer 2

Резьбы могут быть и есть (если они не имеют набора аффинити), перераспределенные во время работы потока. Windows увеличивает нагрузку на все процессоры, чтобы максимизировать производительность.

Answer 3

1) Нить может выделять нить в зависимости от того, какое ядро ​​имеет запасное время обработки. Вот почему вы часто будете видеть программное обеспечение, использующее 50% на четырехъядерной машине, но когда вы проверите графики, используя половину всех четырех.

2) См 1;)

Answer 4

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

Answer 5

Даже если вы заблокируете нить на одном процессоре, используя SetAffinityMask, QPC может работать в обратном направлении, если вам действительно не повезло, а аппаратная часть отстойна. Лучше просто иметь дело с случаем, когда QPC возвращает плохие значения. В Windows 7 QPC значительно улучшилась в этом отношении, но поскольку вы пишете игру, вы, вероятно, нацеливаетесь на XP, где это вам не поможет.

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

Answer 6

Как правило, нам приходится блокировать нашу игру в один поток при выполнении таймингов из-за этого; нет эффективного пути, который мы нашли, так как вам нужно субмикросекундное разрешение при измерении perf.

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

Аналогично, потому что мы знаем, что например цикл рендеринга всегда будет на ядре 0, мы используем его для временной частоты кадров.