Delphi: Точный таймер (Win API) (комментарии) (5 стр)

MrShoor
> Это как? Вот допустим происходит вызов QPC, винда сохраняет все регистры в
> текущем треде, ждет когда освободится нужный тред и читает там таймер?
Почти, прямая рекомендация от мелкомягких на тот момент была оборачивать вызов QPC в  SetThreadAffinityMask/GetThreadAffinityMask.

{
  save = GetThreadAffinityMask();
  ret = QPC;
  SetThreadAffinityMask(save);
}

И да SetThreadAffinityMask

> Звучит крайне не очень на мой взгляд. Я бы предположил
Тогда были именно такие рекомендации. Вполне возможно, что они как то это с оптимизировали. Может даже так как ты описал.

Delfigamer
> Что? Нет же.
Выдели в этом коде семпл и потом точку(точнее все возможные) внутри семпла в которой(ых) тред может проснутся после получения слайса. И увидишь что - да.

> Если один сэмпл пересечёт границу - то только этот сэмпл и пересечёт, с чего
> это вдруг остальные должны как-то от этого поменяться?
Напомню, ты сам сказал, что (в идеальных условиях):

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

Cheb
> Нет, если использовать, как я, релятивистский таймер, основанный на запоминании
> предыдущего значения TSC и сравнивания с текущим.
Только он (бывает иногда) запоминает значения разных TSC. У каждого ядра свой счетчик и иногда они не синхронизированны. И каждый раз дергая rdtsc ты получаешь значение одного из нескольких счетчиков. Какого именно ты не знаешь.

> Он не даёт "время, прошедшее с t0", он даёт "время, прошедшее с предыдущего
> вызова", что актуально при профайлинге.
Да только по ошибке он может смотреть это время на разных часах. О том и речь.

> QPC использует TSC на процах, поддерживающих invariant TSC
Да.

> Можно довериться ей, или можно сделать всё самому и поиметь небольшой профит во
> времени вызова.
Можно делать и самому. Но тогда придется дергать ThreadAffinityMask для гарантии или предварительно убеждаться что данное конкретное железо синхронизированно. И профит ты получаешь в том числе за счет выкидывания синхронизации.

exchg
Не путай людей, вот цитаты из приведенной ссылки

И вот

return [](){};
> Не путай людей
В чем именно я их путаю? Если ты пропустил, то напомню, что речь идет о чистом rdtsc, то что современный QPC исправлен уже говорилось. Касаемо QPC и масок речь идет сугубо в прошлом времени.

А так  твои цитаты только подтверждают то, о чем говорю я. Проблема c чистым rdtsc есть и ее исправляют внутри QPC. В чем я людей путаю непонятно.

return [](){};
Cheb
> З.Ы. Нашёл статью, где *очень* подробно всё расписано, по версиям виндовс и
> степеням древности проца.
> https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-…
> n-time-stamps

Рекомендую обратить внимание на текст под вашей ссылкой:

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

Ну попался у нас плохой сэмпл, в начале измерили T1, а в конце - T2+5000, и дельта съехала на T2-T1.
Следующий сэмпл начинается в T2+5500 и заканчивается 5000 тактов спустя.
Так с чего это он пересечёт границу, когда от начала слайса не прошло и 5000 тактов, а полная длина слайса - это 10000000?
Зачем винда будет переключать контекст на каждом сэмпле? Ты понимаешь, что по твоим словам, винда ловит прерывания по десять раз каждую микросекунду, и каждый раз она рандомно перекидывает потоки между ядрами? Ты осознаёшь, что это полный бред, и если бы кернел действительно так делал, то процессор проводил бы больше времени в шедулере, чем в самих программах, и все кэши ниже L3 ушли бы на помойку?
Ты серьёзно не понимаешь, о чём идёт речь, или это такой толстый троллинг?
Или тебе нужно картинку нарисовать? Вот тебе картинка:

sample |---| |xxx| |---| |---| |---| |---| |---| |---| |---| |---| |---| |xxx| |---|
slice  -------||-----------------------------------------------------------||-------

С какого такого перепугу разрыв между слайсами должен оказаться во всех сэмплах? Как такое вообще возможно? Как о таком можно вообще подумать? Или ты всё-таки притворяешься и на самом деле это такое испытание на терпение?

Delfigamer
>Да схрена ли?
А как по твоему это работает? ))))

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

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

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

> Ты осознаёшь, что это полный бред, и если бы кернел действительно так делал, то
Symmetric multiprocessing. Собирай с пола обрывки шаблона.

> Ты серьёзно не понимаешь, о чём идёт речь, или это такой толстый троллинг?
Я серьезно понимаю.

> Или тебе нужно картинку нарисовать? Вот тебе картинка:

UPD
Ааа, я понял. Я вначале подумал что |xxx| это rdtsc запрос. В таком раскладе то, что я отрезал не актуально.

Delfigamer
> когда от начала слайса не прошло и 5000 тактов, а полная длина слайса - это
> 10000000?
Если мы допустим что оно так, то т.к.:
*ты не можешь знать размер сэмпла наперед, ты его как раз измеряешь.
*размер слайса тоже не константа (даже близко). Даже больше эта величина вне твоей системы вообще. На нее закладываться вообще нельзя.

То возникает законный вопрос (если откинем послезнание) на основании чего сделан вывод, что семпл будет меньше слайса? )))

UPD
Подкину еще дегтя в твой метод, если тред проиграет контеншин по приоритету, то его выкинут с ядра еще до конца слайса. Т.е. реально смена ядра может случаться не в конце слайса, а в конце кванта.

Вообще сам подход с огородом вызывает у меня аналогию вот с таким:

{
  int *i = malloc(sizeof(*i));
//  Проверка излишня, т.к. памяти у нас гагабайты, мы можем быть 
//  уверены, что несколько байт найдутся всегда.
  *i = 1234;                    
}

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

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

чем пользоваться то?)

Mira
> чем пользоваться то?)
Чем угодно, в том числе, и вариантом от Delfigamer, если ты точно понимаешь как это все работает и что именно ты меряешь. Если ничего не понимаешь, то слушай рекомендации разработчиков конкретной системы.

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

Mira
> и какой вывод из всего этого можно сделать?
> QPC продуман, но за один его вызов уже убежит хрен знает сколько тактов.
QPC может быть медленным там, где RDTSC будет неточным. Там где RDTSC точный - QPC максимально быстрый. Так что просто используй QPC.

Mira
> эта тема меня навела на размышления, не поменять ли таймер.
Ну если слушать разработчиков windows то они рекомендуют QPC. В общем было бы интересно увидеть сравнение графиков QPC и RDTSC

Delfigamer
Подкину еще дегтя в твой метод, если тред проиграет контеншин по приоритету, то его выкинут с ядра еще до конца слайса. Т.е. реально смена ядра может случаться не в конце слайса, а в конце кванта.