Mail Archives: djgpp/2000/04/17/05:32:30
On Sun, 16 Apr 2000, Alexei A. Frounze wrote:
> > So what I would suggest would be to write the entire (or as much code as
> > possible) using C..then you can run gprof and see which routines are
> > taking up the most cpu time...and belive me you will be surprised...
> > *then* you can decide on what routines to optimise or not...
>
> No, I won't be surprised.
IMHO, it's hardly a good idea to ignore the accumulated experience of
many programmers, including such able programmers as Jon Bentley and
Don Knuth. Everyone who has ever tried to use a profiler will tell
you that more often than not, the results are surprising.
Those who think they know better where their program spends most of
its time, are bound to rediscover the truth through their own bitter
experience. The ``bitter experience'' in this case is to spend many
hours optimizing some code to death, only to discover that the program
was sped up by 5%...
Did you profile your program? If not, why not? The profiler sits
right in your bin subdirectory, waiting to be used. At the very
worst, it will show you that your expectations were correct, so what
do you have to lose, exc except a recompile and a few moments reading
the profile?
> > And also I find that surprisingly enough a good optimizing compiler
> > produces faster code than a hadwritten assembly sequence. Because the
> > compiler can optimize the output of the C code taking in to advatage the
> > cpu characteristics of various x86 architectures...
>
> Not really. The inner loop in my tmapper can not be written in pure C. Belive
> me. No one compiler figure out such a trick as used in my ASM module.
The usual rule of thumb is that the most clever assembly code can
yield a speed-up of 30-50% at the most. If you are not talking about
the single inner-most loop of your program, the net effect on the
program will not be too profound.
The profiler is the proper tool to judge that.
> I'm sure advanced programmer is much more clever than a compiler.
> At least I treat myself as an advanced one and usually this is proved by the
> achieved results.
IMHO, you should look at the code produced by GCC more often, to put
this into a proper perspective.
- Raw text -