>[snip]
>: loop: movl %eax,%ebx
>: addl %edx,%ecx
>: decl %eax
>: jne loop
>: takes only 2 cycles but the loop used to measure BogoMIPS
>: loop: decl %eax
>: jne loop
>: takes 5 because of pipe stalling.
>: Though I think we can safely say that the only thing you can do faster with
>: a i486 than with a pentium is a two instruction loop. Unfortunately this is
>: exactly how BogoMIPS are calculated.
>Why does the kernel not use the first example you give? If this is more
>accurate, then does using the second example imply that time critical
Because the first sequence is much slower on 386SX and 386DX machines and
would result in much less accurate timing on those processors.
Quote:>sections of the kernel which rely on the bogomips count to give a measure of
>CPU speed, are being fed incorrect information. I'm sure most, if not all
No. The BogoMips loop is merely used as a kind of ``delay constant''.
During booting the kernel times how often that loop can be executed in a
fixed time period. Given the number of loop executions per second the
kernel routine udelay(n) can then compute how many times it has to execute
the loop in order to produce an ``n'' micro second delay.
So, the actual time needed by the delay loop itself (__delay() in the
kernel source) is not important, as long as it is constant and short enough
to get a little accuracy. The only ``advantage'' of having a faster loop is
that your BogoMips rating will go up. The disadvantage is of course that
on faster machines the udelay computations may overflow.
The purpose of the udelay() stuff is to provide micro second delays in
device drivers where simple loops like
(for (i=0; i<10000; i++)
nop();
vary too much in time over various processors. [386SX is *much* slower
than Pentium for the same loop!]
If the delay loop actually needs more cycles on a Pentium, that would
be a *Good Thing* (TM ;-) because it allows the same delay loop to be used
on both slow 386SX CPUs and faster Pentium CPUs without risking overflows
in the udelay() stuff. Someday the processors will be so fast that the code
will have to be revised in order to avoid overflows on fast machines
Quote:>of such loops are of more than two instructions!
>David
>--
Hennus
BogoMips: n. [Linux] A {bogus} indication of processor performance
on the ultimate {benchmark}, a dummy loop consisting of only a
decrement instruction and a branch instruction. It was deliberately
designed to be slower on faster machines, causing a lot of confusion
on {Usenet}. (See {MIPS} and {bogon}.)
--
PGP fingerprint: 76 99 FD 31 91 E1 96 1C 90 BB 22 80 62 F6 BD 63
"when privacy is outlawed, only outlaws will have privacy"