From:	"John M. Aldrich" <fighteer AT cs DOT com>
Newsgroups:	alt.os.linux,comp.os.msdos.djgpp
Subject:	Re: GCC test velocity on DOS and Linux
Date:	Wed, 15 Apr 1998 18:25:51 -0400
Organization:	Two pounds of chaos and a pinch of salt.
Lines:	67
Message-ID:	<353533EF.1EB@cs.com>
References:	<6gtfu7$kog$1 AT talia DOT mad DOT ibernet DOT es>
NNTP-Posting-Host:	ppp228.cs.com
Mime-Version:	1.0
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp

Javi wrote:
> 
> GCC is about 200 times faster in LINUX than under DOS, even in a i486.
> Compile my source code using time.h and stdio.h.

Please don't post encoded binary files on the newsgroup; not everybody
here can easily read them.  If you want to post sample code, please do
it in text format.  Also, do NOT post executables, for two reasons.  The
first is that nobody wants to spend the time to download them.  The
second is that executables could contain viruses or be trojan horses,
and there's no way to tell in advance of running them.  Providing only
the code should be sufficient for anybody who wants to test it.  If I
have Linux, there's no reason why I couldn't compile it myself, and if I
don't, I can't run the program anyway.

Extremely slow DJGPP compilation times are almost always a result of a
bad user configuration.  Have you read chapter 7 of the DJGPP Frequently
Asked Questions list?  Don't complain until you've tried the tips listed
there.  Afterwards, go right ahead.

Nevertheless, I just tried out your code.  I don't have Linux to work
with, but I now understand that you are talking about program execution
speed, not compilation speed.  Please make this obvious; we aren't
mind-readers here.  The code reported 37261 on my K6-233 under Win95.  I
have no idea if this is good or not, because in addition to not telling
us what you were testing, you also didn't tell us what results you got. 
This makes it very difficult to compare benchmarks.

After my initial run, I decided to recompile with profiling enabled to
see where the program was spending most of its time.  In a total run of
4.72 seconds, 4.72 of those seconds were spent in time(), and 4.22 in
__dpmi_int.  This tells me that the relatively slow results are due to
the fact that DJGPP time() calls a real-mode interrupt, which requires a
PM<->RM mode switch.  Since mode switches are extremely expensive in CPU
cycles, of _course_ you get poorer results than you would expect!

How would I fix this?  If I substitute uclock() for time(), and test for
10 * UCLOCKS_PER_SEC, your supposed "benchmark" result comes out to be
844357, which is 22 times faster.  If I use clock() instead, the result
is a whopping 65874607, which is 1767 times faster than using time(). 
The command line I used in all cases was the following:

   gcc -Wall -g -O pr.exe pr.c

For profiling runs, I added the '-pg' switch.  The only relevant switch
is -O, for optimization.  You didn't say whether you optimized your code
or not; this too can have a significant effect on performance.

Please don't post such provocative statements without fully documenting
your methods and results and ensuring that there are no flaws in your
test suite itself.  Your error comes from making assumptions about the
performance of library functions on different platforms, which is a
major no-no in any programming language.  Remember, "assume" makes an
"ass" of "u" and "me".

BTW, it's illegal C for main() to return anything other than an
integer.  But I "assume" you already knew that.

Have a nice day!

-- 
---------------------------------------------------------------------
|      John M. Aldrich       |"Men rarely (if ever) manage to dream |
|       aka Fighteer I       |up a god superior to themselves. Most |
|   mailto:fighteer AT cs DOT com   |gods have the manners and morals of a |
| http://www.cs.com/fighteer |spoiled child."    - Lazarus Long     |
---------------------------------------------------------------------

- Raw text -