Subrealist писал(а):
Данные по точности из того значения, которое возвращает QueryPerformanceFrequency и того, которое принимает Sleep.
если можно, поподробнее,
из этого, я ничего не понял, честно говоря
какая связь может быть между QueryPerformanceFrequency и Sleep в отношении точности?
Subrealist писал(а):
А что вам мешает его в уме подставить?
в уме его представить вообще-то невозможно,
вернее, конечно можно, но это уже будут исключительно ваши фантазии,
а скомпилирован он будет по строго заданным законам оптимизации, принятым тем или иным компилятором (и программистом, конечно же), так что о том, сколько там будет инструкций и сколько они будут считаться вы опять же можете только фантазировать, пока не увидите листинг машинного кода
Subrealist писал(а):
Или сделать обратную замену ассемблерного кода на intrinsic функцию? В чём проблема то?
вот поэтому я и сказал, что асм тут был лишний
Subrealist писал(а):
А в чём такая уж сложность? Учитывая, что у меня сама голая процедура замера времени занимает 80 тактов, реализована инструкция rdtsc не совсем просто и в микрокоде занимает не одну операцию.
сложность не в реализации инструкции, а в том, чтобы синхронизировать аппаратные счетчики на разных процессорах, учитывая то, что сама rdtsc не должна синхронизироваться даже с кэшем, т.е. она не ждет завершения каких-либо уже начатых или законченных, но не возвращенных операций, а выполняется непосредственно тогда, когда ее позвали, поэтому ее результат по большей части зависит от окружения, в котором она используется,
по этому поводу intel и пишет:
Цитата:
The RDTSC instruction is not a serializing instruction. It does not necessarily wait
until all previous instructions have been executed before reading the counter. Similarly,
subsequent instructions may begin execution before the read operation is
performed. If software requires RDTSC to be executed only after all previous instructions
have completed locally, it can either use RDTSCP (if the processor supports that
instruction) or execute the sequence LFENCE;RDTSC.
вот и вызывайте intrinsic _mm_lfence перед замером,
у меня пустой замер занимает 24 тика TSC с LFENCE и порядка 500-700 - без нее,
аналогичные результаты и при закреплении расчета на одном ядре - 24 тика, на 4-хядерном Core i3
так что берем поправку "на ветер" и вперед, с музыкой и максимально-доступной точностью,
только надо учесть инертность таких подходов,
можно сказать, это "идеальное", "нереальное", а по вашему, видимо - "астрономическое" время,
которого в современном процессе быть не может, поскольку машинный код может быть и распараллелен по нескольким конвейерам, и размазан по нескольким микрокомандам на этом конвейере, и реальная скорость может измениться уже просто исходя из порядка выполнения операций, а учитывая дополнительную синхронизацию с кешами на расчет "астрономического" времени, погрешности тут неизбежны, причем именно в сторону увеличения времени расчетов
а ваши пара сотен операций - как раз под это определение не подходит,
Subrealist писал(а):
Я народ не в чём убеждать не пытаюсь)
"свежо придание, да верится с трудом"
Subrealist писал(а):
А пока в доказательство его работы приводилась лишь несравненная крутость intrinsic-функции __rdtsc и её неоспоримое превосходство над QueryPerformanceCounter, а вся его неработоспособность объясняется отсутствием вызова SetProcessAffinityMask, ну или вставками ассемблерного кода)
я конечно крут, но не до такой степени )),
свои результаты и представил и объяснил, и я не предлагал сделать замер на паре сотен операций, я предлагал показать статистику на паре сотен итераций, если вы не поняли,
а вы, если честно, меня пока только рассмешили невнятным "из того значения, которое возвращает QueryPerformanceFrequency и того, которое принимает Sleep."
Вход
Регистрация
FAQ
Поиск
Но надеюсь кто-нибудь дочитает до этой строчки