Detecting CPU Speed: Difference between revisions

Jump to navigation Jump to search
[unchecked revision][unchecked revision]
Content deleted Content added
No edit summary
removed outdated template
Line 8: Line 8:
using the following :
using the following :


{{Code|pseudo-code|
<pre>
<pre>
prepare_a_timer(X milliseconds ahead);
prepare_a_timer(X milliseconds ahead);
Line 16: Line 15:
cpuspeed_mhz = (iteration_counter * clock_cycles_per_iteration)/1000;
cpuspeed_mhz = (iteration_counter * clock_cycles_per_iteration)/1000;
</pre>
</pre>
}}


Note that except for very special cases, using a busy-loop (even calibrated) to introduce delays is a bad idea and that it should be kept for very small delays
Note that except for very special cases, using a busy-loop (even calibrated) to introduce delays is a bad idea and that it should be kept for very small delays
Line 50: Line 48:
It is possible to create code which is exceptionally pipeline hostile such as:
It is possible to create code which is exceptionally pipeline hostile such as:


{{Code|Example of Pipeline hostile code|
<pre>
<pre>
xor eax,edx
xor eax,edx
Line 58: Line 55:
...
...
</pre>
</pre>
}}


A simple xor instruction takes one cycle, and it's guaranteed that the processor cannot pipeline this code as the current instructions operands depend on the results from the last calculation. One can check that, for a small count (tested from 16 to 64), RDTSC will show the instruction count is almost exactly (sometimes off by one) the cycles count. Unfortunately, when making the chain longer you'll start experiencing code cache misses, which will ruin the whole process.
A simple xor instruction takes one cycle, and it's guaranteed that the processor cannot pipeline this code as the current instructions operands depend on the results from the last calculation. One can check that, for a small count (tested from 16 to 64), RDTSC will show the instruction count is almost exactly (sometimes off by one) the cycles count. Unfortunately, when making the chain longer you'll start experiencing code cache misses, which will ruin the whole process.
Line 89: Line 85:
* it's assumed that the command CPUID is supported.
* it's assumed that the command CPUID is supported.


{{Code|Asm Example|
<pre>
<pre>
;__get_speed__:
;__get_speed__:
Line 126: Line 121:
mov ~[mhz], ax
mov ~[mhz], ax
</pre>
</pre>
}}


See the intel manual (see links) for more information.
See the intel manual (see links) for more information.
Line 135: Line 129:
I'd be tempted to say 'yes', though I haven't gave it a test nor heard of it elsewhere so far. Here is the trick:
I'd be tempted to say 'yes', though I haven't gave it a test nor heard of it elsewhere so far. Here is the trick:


{{Code|Detecting CPU speed without interrupts|
<pre>
<pre>
disable() // disable interrupts (if still not done)
disable() // disable interrupts (if still not done)
Line 148: Line 141:
byte hi=inb(0x40);
byte hi=inb(0x40);
</pre>
</pre>
}}


Now, we know that
Now, we know that
Line 233: Line 225:
==Links==
==Links==


<!--===Related threads in the forum===
===Related threads in the forum===
*Forum:5849
*Forum:5849
*Forum:767
*Forum:767
*Forum:922
*Forum:922
*Forum:8949 featuring info on bogomips, how linux does it and durand's code.-->
*Forum:8949 featuring info on bogomips, how linux does it and durand's code.