Date: Sat, 21 Oct 2000 09:12:28 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: Derek Chew <sdchew AT email DOT com>
Message-Id: <9003-Sat21Oct2000091228+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.5h
CC: djgpp AT delorie DOT com
In-reply-to: <39F0EBB3.375FEFCE@email.com> (message from Derek Chew on Sat, 21
	Oct 2000 09:04:51 +0800)
Subject: Re: Runtime Speed Optimization
References:  <39F0EBB3 DOT 375FEFCE AT email DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: Derek Chew <sdchew AT email DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Sat, 21 Oct 2000 09:04:51 +0800
> 
>   2) I'm not very sure how to provide options to optimize the
>   compiling of the software for my target platform. Going to try -O3
>   but dunno what else can I do. Basically what I want to do is to
>   optimize the program to run as fast as possible.

The key to good optimizations (beyond using the -O2 switch) is
profiling.  Use the Gprof utility to profile your program in several
typical runs.  Gprof's output will show you what functions, if any,
are ``hot spots'', i.e. use a large percentage of the running time.
Take the function whose percentage is the highest and optimize it
first:

   - put that function on a separate module and compile it with the
     best optimization switches (see section 14.2 of the FAQ for some
     guidance);

   - change the algorithm to make that function faster;

If the profile does not find any hot spots, i.e. it is flat, try
various optimization switches on the entire program.  Note that a 486
might need special setting of some options, such as -march, for GCC to
produce an optimal code (the defaults are slated towards a Pentium).

>   3) Sometimes the compiling of the source is done on an old 486SX
>   Laptop which if I am not mistaken does not have an FPU. Does this
>   mean the code generated will always use an FPU emulator even if I
>   run the code later on a 486DX4-100? and is there a way to force the
>   compiler to generate code which will always use an FPU?

The code generated by the compiler does not require an emulator, it
always assumes that an FPU is present.  When a DJGPP program runs on
an FPU-less machine, the startup code loads the emulator, so that the
FP instructions could be caught and emulated.  But the instructions in
the executable program ``don't know'' whether they are emulated or
not.

In other words, a program compiled on a machine without an FPU will
run on 486DX with full speed.  You don't have to worry.