программистское

[avva]

Пишу на ассемблере! Просто чуть ли не "бойцы вспоминают минувшие дни".

       .text
.globl readcounter
readcounter:
        pushl   %ebx
        pushl   %ecx
        subl    %eax, %eax
        cpuid
        rdtsc
        pushl   %eax
        pushl   %edx
        subl    %eax, %eax
        cpuid
        popl    %edx
        popl    %eax
        popl    %ecx
        popl    %ebx
        ret
        .size   readcounter, .-counter

Comments

[avva.livejournal.com]

Потому что "нечестно", ведь сразу после первого запускается pipeline опять, и во время самого замера уже плетет свои гнусные сети со следующими инструкциями. Самое чистое решение - оборвать точку замера с двух сторон. Это даст самую чистую картину поведения. Конечно, с прагматической точки зрения второй обрыв далеко не так важен, как первый, это верно - что оно там успеет сделать, практически ничего.
Но как-то симметричнее и последовательнее так, по-моему. А что касается самих затрат, я все равно буду учитывать (примерные) затраты на cpuid при калибровке результатов, так какая уж разница, один раз или два.

[unbe.livejournal.com]

Я, конечно, не знаю, что именно и как нужно измерить, но мне кажется, второй cpuid сделает только хуже. Он не повлияет на численный результат (в eax:edx то же значение, что и было бы без него), а даст, по сути, только задержку уже после измерения, причем не постоянную, а плавающую. Где смысл? :)

[avva.livejournal.com]

Идея в том, что результат тот же, но если вы после этого повторяете тот же процесс (который изначально замеряли), или еще что-нибудь, что хотите измерить, то разница между следующим значением и этим будет немножко нечестная, потому что CPU начал загружать все в pipelines, prefetch queues итд. итп. еще до того, как закончилась операция rdtsc. Ваше следующее измерение будет чуть меньше реального; подобно тому, как если бы вы не делали первый cpuid, это измерение могло быть меньше реального.

[unbe.livejournal.com]

Я понял, просто не согласен. OOO execution - это нормальный режим работы, и именно в нем получается "реальный" результат. После cpuid часть кода будет выполнена в ненормальных условиях, то есть, потенциально, с другой скоростью. Эта часть может быть из двух кусков - тот, что внутри readcounter, и тот, что снаружи. Первый можно попытаться скомпенсировать при расчетах, второй нельзя. Еще один cpuid просто удлинняет этот второй кусок, делая измерение менее точным.

Проще говоря, если даже в случае без 2го cpuid будет какое-то "убыстрение" (хотя неясно, относительно чего), то в случае с ним будем замедление, которое гораздо труднее учесть.

Против "подобно тому...": первый cpuid делается только чтобы избежать OOO исполнения самого rdtsc. OOO исполнения чего нужно избежать после rdtsc?

Извините, что так длинно :)

[avva.livejournal.com]

Совершенно не надо извиняться. На самом деле спасибо, вы меня убедили :) уберу второй cpuid.

[malaya-zemlya.livejournal.com]

Во-первых, RDTSC синхронизирует pipeline.
Во-вторых, задержка у него самого меняется 90 до 120 циклов в зависимости от знака зодиака и погоды на Марсе, так что абсолютной точности не добиться.

http://softwarecommunity.intel.com/ISN/Community/en-US/forums/thread/30226599.aspx

[shamany.livejournal.com]

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

[malaya-zemlya.livejournal.com]

Я имел ввиду, что второй CPUID тут мало что может поменять.

[avva.livejournal.com]

Да, убедили :) эх, симметричнее было!