Mail Archives: djgpp/1997/01/07/20:57:20
On Mon, 6 Jan 1997, Michael Phelps wrote:
>
> I have been unable to reproduce the claim that integer
> instructions are "thousands" of times faster than floating-point in DJGPP:
<SNIP>
> start_time = uclock();
> for (i = 0; i < ITERATIONS; i++)
> {
> b = (double)random();
> c = (double)random();
> a = b / c;
> }
> end_time = uclock();
<SNIP>
> results on my 5x86/100 under Win95:
> doubles: 2.29s for 1000000 divides
> ints: 2.12s for 1000000 divides
Those times are not just for a million divides, they are for a million
divides plus two million function calls to random() plus two million
long-to-double conversions plus a million integer compares plus a million
integer increments plus a million jumps plus a single call to uclock()
plus God knows howmany additional loads & stores, and since you are
running under Windows, even He doesn't know what overhead is being added
by the "OS". If you want to time the divides, you have to time the loop
*without* the divides and subtract it from the loop *with* the divides. I
think that you will find that each divide takes significantly less than 2
microseconds.
> conclusions: on my machine, at least, there is not a significant
> difference in speed between integer and floating-point math. (The program
> was compiled with -O2, by the way).
Since your times included such a large chunk of overhead (and non-constant
non-predictable non-repeatable overhead at that), you are not really
comparing the divide times, so your conclusion that there is no
significant difference between dividing ints and dividing doubles is not
valid. When I subtracted the program overhead time, I found that on my
p5-133, int divides appear to take roughly one-and-a-half times as long as
double divides.
Furthermore, when I run the program in a full-screen dos box under win3.1,
I get different speeds each time I run it, and ratios varying between
about 1.2 and 1.9, so I'd say you can't conclude much (if anything) using
this approach. Run under pure dos, turn off all optimizations, and
carefully account for all overhead, and you *might* get something
meaningful.
--Phil Galbiati
=================================================
Any opinions expressed here reflect the
ignorance of the author, NOT Tektronix.
=================================================
- Raw text -