Board index » delphi » rdtsc vs. GetTickCount()

2005-08-28 09:41:08 PM
delphi88
The following function (from the MM Challenge) does not compile in
Delphi 5. Is it save to replace this with GetTickCount for
compatibility, or will that cause problems?
function GetCPUTicks: Int64;
asm
rdtsc;
end;
--
Regards,
Bruce McGee
Glooscap Software
 

Bruce McGee writes:
rdtsc;
to
db $0F; db $31; //rdtsc
Regards
Lars G
 

At 15:41:08, 28.08.2005, Bruce McGee writes:
different granularity.
RDTSC was not known to the D5 compiler. You can probably emulate it with
asm
dw $310F
end;
--
Rudy Velthuis [TeamB] velthuis.homepage.t-online.de
"Never interrupt your enemy when he is making a mistake."
- Napoleon Bonaparte (1769-1821)
 

Hi Bruce
We do not support D5. Doing nothing is OK, but it is very cheap to db the
instruction as suggested by Lars.
Best regards
Dennis
 

Dennis writes:
of erring on the side of compatibility if it doesn't cost much. This
way at least the B&V isn't the limiting factor.
Unfortunately, it looks like there are other instructions (CPUID,
ANDPS) and incompatibilities with Delphi 5 that might not be worth
retro-fitting.
--
Regards,
Bruce McGee
Glooscap Software
 

Lars writes:
Thanks.
--
Regards,
Bruce McGee
Glooscap Software
 

Rudy Velthuis [TeamB] writes:
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
 

why not use QueryPerformanceCounter QueryPerformanceFrequency?
"Bruce McGee" <XXXX@XXXXX.COM>writes

On 28 Aug 2005 09:33:12 -0700, "Bruce McGee" <XXXX@XXXXX.COM>
writes:
--
Anders Isaksson, Sweden
BlockCAD: web.telia.com/~u16122508/proglego.htm
Gallery: web.telia.com/~u16122508/gallery/index.htm
 

Hi
I use QueryPerformanceCounter & QueryPerformanceFrequency in all the B&V's.
IMHO. There is no need to change something that works in the MM B&V.
Best regards
Dennis
Donate to the Fastcode Project:
dennishomepage.gugs-cats.dk/FastCodeProject.htm
 

Anders Isaksson writes:
I haven't looked at any other B&Vs aside from the MM challenge, so i
don't know if the CPU and OS information functions are part of a common
FastCode library or not. If they aren't, they should be.
--
Regards,
Bruce McGee
Glooscap Software
 

Sasa Zeman wrote in <XXXX@XXXXX.COM>:
into account, but you're much less likely to have a rollover with
RDTSC. Also, RDTSC works at the clock-cycle level, a much more
meaningful value than milliseconds (which don't take into account
processor speed-- e.g.: a 500 MHz Pentium III vs. a 3.2 GHz Pentium 4).
That's my opinion anyways. :P
*shrug*
Will
--
Want native support in Delphi for AMD64/EM64T? Vote here--
qc.borland.com/wc/qcmain.aspx
 

Hi Will
To me it is much more meaningfull to measure runtime for a function.
If you measure clocktics then you will measure that a 500 MHz Pentium III is
faster than a 3.2 GHz Pentium 4 (which it is not).
We are only comparing function performance so either method is equally good.
Why not do as we have done in all other 40 B&V's? Consistency is good.
Best regards
Dennis
 

Dennis wrote in <XXXX@XXXXX.COM>:
Will
--
Want native support in Delphi for AMD64/EM64T? Vote here--
qc.borland.com/wc/qcmain.aspx
 

Hi Dennis,
AMD Cool & Quiet). If you measure with rdtsc then this has little impact,
but it could affect the accuracy when using GetTickCount.
Regards,
Pierre
 

Hi Pierre
Yes. Never benchmark on a system that goes up and down in speed.
Best regards
Dennis