CPU speed detection

[mr. xsism]

i forget the opcode that you can use, but i know you can detect it with some kind of timestamp MIPs opcode.

Does anyone know what it is? Or are there other standard ways ofdoing it?

-mr. xsism

[Tim]

I don't believe you can ask the CPU for its speed, but it's easy to do on a CPU that has the RDTSC instruction (i.e. Pentium and later).

The general idea is:

Code: Select all

start_time = rdtsc();
wait_for_one_second();
end_time = rdtsc();
cycles_per_second = (end_time - start_time) / (1 second);

You can achieve an accurate one-second wait using the real-time clock.

[Therx]

I didn't know about rdtsc insturction but if you disable task switching you could do a loop:-

Code: Select all

int i = 0, sec = 0;
while(sec == 0)
 i++;

Then work out how many CPU cycles one pass of the loop takes. Then once the RTC ISR (which must not interrupt at all until one second) sets sec to 1. Then multiply i by the number of cycles/pass.

Long winded but I got it to work accurately in the past.

Pete

EDIT :
Found my original code. The first wait is to make sure that you start at 1 sec so that 2 sec will be a wait of 1 sec. (ie not 1.9 to 2 = 0.1sec)

Code: Select all

int getCPUspeed()
{
   set_sched(0);
   int i = 0;
   rtc_timer = 1;
   while(rtc_timer == 1);
   rtc_timer = 1;
   while(rtc_timer == 1)
   {
      i++;
   }
   set_sched(1);
   return i / 500 / 1000;
}

Clearly the loop is two cycles long so speed = i * 2 / 1000 / 1000; to get MHz

[Pype.Clicker]

keep in mind that the 'RTC' interrupt has a quite low priority, so it could be wise to mask any higher interrupts (keyboard, mouse, PCI, IRQ0, etc) if you want a precise result.

[Tim]

Clearly the loop is two cycles long so speed = i * 2 / 1000 / 1000; to get MHz

Whoa... BIG assumption here.

Even if you wrote the loop in assembly code, and it was two instructions long, it wouldn't necessarily be two cycles long. The point of using RDTSC on newer processors is that you can't rely on instruction timings any more. In fact, I don't think Intel etc. have published instruction timings since the days of the 486 as they are now meaningless.

[Candy]

Clearly the loop is two cycles long so speed = i * 2 / 1000 / 1000; to get MHz

Whoa... BIG assumption here.

Even if you wrote the loop in assembly code, and it was two instructions long, it wouldn't necessarily be two cycles long. The point of using RDTSC on newer processors is that you can't rely on instruction timings any more. In fact, I don't think Intel etc. have published instruction timings since the days of the 486 as they are now meaningless.

You should realise they are no more meaningless than they were back then. If you want to optimise at that level, you can, and you should even be able to. I know for myself that AMD does publish those kind of optimization tables (including in which pipeline it can be processed) and the number of instructions the instruction decoder can decode in their docs. Made an MMX translucent-per-pixel-copy routine that takes 10 cycles per pixel

[Curufir]

Made an MMX translucent-per-pixel-copy routine that takes 10 cycles per pixel

Would that be on the first or second run through the loop? Operating on data with separate cache-lines or only one cache-line? What state are the BTB entries in? Etc.

There's a whole lot more going on inside a modern processor than just interpreting instructions. It's this extra, and largely opaque, optimising that makes figuring out cycle time on paper so difficult. The published instruction timings should be used as an estimate, nothing more.

[RDTSC]

RDTSC reads the current "Time Stamp Counter" to EDX:EAX pair ( the counter which pentium+ CPUs increment every clock cycle )

just read the TSC, wait for 1 sec, read it again, the difference is the "Hz" of your CPU, it will read appr. ( 10 pow 9 ) on a 1000 MHz pc.

remember RDTSC is an assembly command.