From: Philip S Galbiati Newsgroups: comp.os.msdos.djgpp Subject: Re: FP vs int timings Date: Tue, 7 Jan 1997 12:31:51 -0800 Organization: Tektronix, Inc, Beaverton, OR, USA Lines: 59 Message-ID: References: NNTP-Posting-Host: mdjunior.cse.tek.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In-Reply-To: To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp 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: > start_time = uclock(); > for (i = 0; i < ITERATIONS; i++) > { > b = (double)random(); > c = (double)random(); > a = b / c; > } > end_time = uclock(); > 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. =================================================