Detecting CPU Speed: Difference between revisions
[unchecked revision] | [unchecked revision] |
Content deleted Content added
No edit summary |
m Bot: Replace deprecated source tag with syntaxhighlight |
||
(16 intermediate revisions by 13 users not shown) | |||
Line 1:
==What is CPU Speed==
"CPU speed" has several different definitions:
# How quickly the processor can execute code (e.g. instructions per second)
# How fast the processor's clock is running (e.g. cycles per second)
How quickly a CPU can execute code is important for determining the CPU's performance. How fast a CPU's clock is running is only useful for specific cases (e.g. calibrating the CPU's TSC to use for measuring time).
There are also several different measurements for these different "CPU speeds":
# Best case
# Nominal case
# Average case
# Current case
# Worst case
For example, look at a modern Intel Core i7 CPU (with turbo-boost, power management and hyper-threading). The best case instructions per second would occur when:
# There is no throttling/power saving at all.
# Only one logical CPU is running (turbo-boost activated and hyper-threading not being used)
# Simple instructions with no dependencies in a loop that fits in the CPU's "loop buffer" are being executed
# There are no branch mispredictions
# There are no accesses to memory (no data being transferred to/from caches or RAM)
The worst case instructions per second would be the exact opposite and may be several orders of magnitude worse (e.g. a best case of 4 billion instructions per second and a worst case of 100 million instructions per second). The nominal instructions per second (commonly referred to as "nominal cycles per second") is an estimation of the normal average instructions per second a developer would expect. All of these things are fixed values - a specific CPU always has the same best case, worst case and nominal case, and these values don't change depending on CPU load, which instructions are/were executed, etc.
The current instructions per second is the instructions per second at a specific instant in time and must be somewhere between the best and worst cases. It can't be measured exactly, but can be estimated by finding the average instructions per second for a very short period of time. The average case is something that has to be measured. Both the current instructions per second and the average instructions per second depend heavily on the code that was running. For example, the average instructions per second for a series of NOP instructions may be much higher that the average instructions per second for a series of DIV instructions.
==General Method==
In order to tell what
#
#
Once these two sub-problems are solved, one can easily tell the CPU speed
using the following :
<pre>
prepare_a_timer(X milliseconds ahead);
Line 16 ⟶ 42:
cpuspeed_mhz = (iteration_counter * clock_cycles_per_iteration)/1000;
</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
(nano or micro seconds) that
Also note that PC emulators (like BOCHS, for instance) are rarely realtime,
than expected.
=== Waiting for a given amount of time ===
There are two circuits in a PC
The PIT has two operating
# the ''periodic interrupt'' mode (0x36), in which a signal is emitted to the interrupt controller at a fixed frequency. This is especially
# the ''one shot'' mode (0x34), in which the PIT will decrease a counter at its top speed (1.19318 MHz) until the counter reaches zero.
Whether or not an IRQ is fired by channel0 in 0x34 mode should be checked.
Note that
=== Knowing how many cycles your loop takes ===
This step depends on
a well-known and deterministic amount of clock cycles to execute. This
the programmer to tell exactly how many cycles a loop iteration took by looking
up the timing of each instruction and then
Since the multi-pipelined architecture of the Pentium
no longer communicated (for a major part because the same instruction could have
variable timings depending on its surrounding, which makes the timing almost useless).
It is possible to create code which is exceptionally pipeline hostile such as:
<syntaxhighlight lang="asm">
xor eax,edx
xor edx,eax
Line 57 ⟶ 80:
xor edx,eax
...
</syntaxhighlight>
A simple xor instruction takes one cycle,
E.g. [http://www.sylvain-ulg.be.tf/resources/speed.c looping on a chain of 1550 XORs] may require a hundred of iterations before it stabilizes around 1575 clock cycles on a AMDx86-64
Despite this inaccuracy, it gives relatively good results across the whole processor generation given a reasonably accurate timer.
A Pentium developer has a much better tool to tell timings: the
[http://www.math.uwaterloo.ca/~~jamuir/rdtscpm1.pdf rdtscpm1.pdf] explains how that feature can be used for performance monitoring and should provide the necessary information on how to access the TSC on a
===RDTSC Instruction Access===
The presence of the Time Stamp Counter (and thus the availability of RDTSC instruction) can be detected through the [CPUID] instruction.
Note that prior to
In the case of a processor that does not support CPUID, you'll have to use more eflags-based tests to tell if
=== Working Example Code===
Some notes:
* ''irq0_count'' is a variable, which increases each time when the timer interrupt is called.
*
*
<syntaxhighlight lang = "asm">
;__get_speed__:
;first do a cpuid command, with eax=1
Line 96 ⟶ 117:
cpuid
test edx,byte 0x10 ; test bit #4. Do we have TSC ?
;wait until the timer interrupt has been called.
mov ebx, ~[irq0_count]
Line 125 ⟶ 146:
; ax contains measured speed in MHz
mov ~[mhz], ax
</syntaxhighlight>
See the
:- bugs report are welcome. IM to [http://www.mega-tokyo.com/forum/index.php?action=viewprofile;user=DennisCGc DennisCGC]
=== Without Interrupts ===
{{Tone}}
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:
<syntaxhighlight lang="C">
disable() // disable interrupts (if still not done)
outb(0x43,0x34); // set PIT channel 0 to single-shot mode
Line 147 ⟶ 168:
byte lo=inb(0x40);
byte hi=inb(0x40);
</syntaxhighlight>
Now, we know that
Line 163 ⟶ 183:
== Asking the SMBios for CPU speed ==
{{Main|SMBIOS}}
The [[
Do note that SMBIOS was never intended for initialization purposes. It was intended to provide information for asset management systems to quickly determine what computers contained what hardware. Unfortunately this means that it might be quite unreliable, especially on cheap/home systems. So ultimately it may not be the best way to determine CPU speed.
===SMBios Processor Information===
A Processor information (type 4) structure describes features of the CPU as detected by the SMBios. The exact structure is depicted in section 3.3.5 (p 39) of the [http://www.dmtf.org/standards/documents/SMBIOS/DSP0134.pdf standard]. Within
* the External Clock (bus) frequency, which is a word at offset 0x12,
* the Maximum CPU speed in MHz, which is a word at offset 0x14 (e.g. 0xe9 is a 233MHz processor),
Line 179 ⟶ 202:
As an alternative, you can locate the _SMBIOS Entry Point_ and then traverse manually the SMBIOS structure table, looking for type 4.
All this is depicted in '
==Links==
*Forum:5849
*Forum:767
*Forum:922
*Forum:8949 featuring info on bogomips, how linux does it and durand's code.
* https://forum.osdev.org/viewtopic.php?f=1&t=32808
===Other resources===
* http://
* http://www.sandpile.org/post/msgs/20004561.htm
* http://www.midnightbeach.com/jon/pubs/rdtsc.htm
Line 255 ⟶ 229:
[[Category:X86 CPU]]
[[Category:Hardware Detection]]
|