Board index » delphi » rdtsc vs. GetTickCount()

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
 
 

Re:rdtsc vs. GetTickCount()

Bruce McGee writes:
Quote
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;

My proposal is to change
rdtsc;
to
db $0F; db $31; //rdtsc
Regards
Lars G
 

Re:rdtsc vs. GetTickCount()

At 15:41:08, 28.08.2005, Bruce McGee writes:
Quote
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;
GetTickCount will not give you the same number. It has a very, very
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)
 

Re:rdtsc vs. GetTickCount()

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
 

Re:rdtsc vs. GetTickCount()

Dennis writes:
Quote
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
I know D5 isn't officially supported by FastCode. I just like the idea
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
 

Re:rdtsc vs. GetTickCount()

Lars writes:
Quote
My proposal is to change

rdtsc;

to

db $0F; db $31; //rdtsc

Regards
Lars G
Done. it is certainly cleaner than using ifdefs.
Thanks.
--
Regards,
Bruce McGee
Glooscap Software
 

Re:rdtsc vs. GetTickCount()

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

Re:rdtsc vs. GetTickCount()

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

>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

I know D5 isn't officially supported by FastCode. I just like the idea
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
 

Re:rdtsc vs. GetTickCount()

On 28 Aug 2005 09:33:12 -0700, "Bruce McGee" <XXXX@XXXXX.COM>
writes:
Quote
Unfortunately, it looks like there are other instructions (CPUID,
ANDPS) and incompatibilities with Delphi 5 that might not be worth
retro-fitting.
Why not take a look at Avatar's IntToStrB&V? That one compiles in D5.
--
Anders Isaksson, Sweden
BlockCAD: web.telia.com/~u16122508/proglego.htm
Gallery: web.telia.com/~u16122508/gallery/index.htm
 

Re:rdtsc vs. GetTickCount()

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
 

Re:rdtsc vs. GetTickCount()

Anders Isaksson writes:
Quote
Why not take a look at Avatar's IntToStrB&V? That one compiles in D5.
Nice. Good implementation and clean code.
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
 

Re:rdtsc vs. GetTickCount()

Sasa Zeman wrote in <XXXX@XXXXX.COM>:
Quote
GetTickCount method always return quite realistic value.
GetTickCount can roll over. Not a showstopper if you take said rollover
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
 

Re:rdtsc vs. GetTickCount()

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
 

Re:rdtsc vs. GetTickCount()

Dennis wrote in <XXXX@XXXXX.COM>:
Quote
Why not do as we have done in all other 40 B&V's? Consistency is good.
Sure, sounds good to me.
Will
--
Want native support in Delphi for AMD64/EM64T? Vote here--
qc.borland.com/wc/qcmain.aspx
 

Re:rdtsc vs. GetTickCount()

Hi Dennis,
Quote
We are only comparing function performance so either method is equally
good.
Some CPUs dynamically adjust clock speeds according to the system load (e.g.
AMD Cool & Quiet). If you measure with rdtsc then this has little impact,
but it could affect the accuracy when using GetTickCount.
Regards,
Pierre
 

Re:rdtsc vs. GetTickCount()

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