Re: rdtsc vs. GetTickCount()

Rudy Velthuis [TeamB] wrote:

> GetTickCount will not give you the same number. It has a very, very
> different granularity.

In fact, my results are totaly oposite. RDTSC is too much sesitive on
background/threaded actions, in fact any previous action (before
measure start) have effect. At least that is the fact for W2K SP3 and
Celeron 1.3GHz environment.

Simple code:

function RDTSC: Int64;
asm
DW $310F
end;


procedure TForm1.Button1Click(Sender: TObject);
var
t1: Int64;
t2: Cardinal;
b: Tbitmap;
begin

t2:=GetTickCount;
t1:=RDTSC;

B:=TBitmap.Create;
B.Free;

t1:=RDTSC-t1;
t2:=GetTickCount-t2;

Caption :=inttostr(t1)+' CPU Clock Cycles '+inttostr(t2)+' ms';
end;

In this case, Cycles Clock counter receive larger value instead of that
if GetTickcount do not exist in the upper example. In case of reseving
memory before starting measure with RDTSC, all calculation is not
precise. In fact, value can be larger 1.000-100.000 Clocks, or even 2
or 3 times in case of small CPU consuming code. Methods to set
processes priority before starting test are usually ineffective.
Repeading the same testing code several times (5-50 or even more) and
saving smaller value can give very near to exact result.

GetTickCount method always return quite realistic value. Oonly problem
is if necessary CPU time for testing code is less than 50 ms. In
generally, useful interval is above 500-1000 ms. With suitable number
repeating code to exceed that limit, GetTickCount method is quite
precise (if all code work with data in memory).

All background applications (as is AVP and similar) are always closed
in both measures (RDTSC and GetTickCount). I have both speed test
methods in speed demo for SZCodeBaseX unit on my site, which
demonstrate all upper wrote.

If you have other methods/preparations to recive beter precise results
with RDTSC, It would be interesting to elaborate.

Sasa
--
www.szutils.net
.

Quantcast