delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/04/17/05:51:00

Message-ID: <38FAC36B.DD34F8C9@mtu-net.ru>
Date: Mon, 17 Apr 2000 11:55:23 +0400
From: "Alexei A. Frounze" <alex DOT fru AT mtu-net DOT ru>
X-Mailer: Mozilla 4.72 [en] (Win95; I)
X-Accept-Language: en,ru
MIME-Version: 1.0
To: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp AT delorie DOT com
Subject: Re: inefficiency of GCC output code & -O problem
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000417101929 DOT 14867F-100000 AT is>
X-Recipient: eliz AT is DOT elta DOT co DOT il
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:
> 
> 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.

Guys, it's *my* program and belive me I know how it works. I'm not just a
newbie. :)) For sure, I'll try GPROF or something similar for finding how much
time is spent on different parts of the code. But I won't wonder. I know what i
expect of it.

> 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%...

Okay, if there are only 2 subroutines that *always slow* regardless of the
author name, compiler but just depending on the algorithm used and amount of
data needed to be processed, do I need to find them again??? I know their names:
T_Map() and Scan_Edge(). Or you're talking ion general? Forgive me, if so. :)


> 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?

Yes, I profiled it but w/o a profiler. Just with use FPS counter and RDTSC in
some time-critical parts. These results are anough for me. I know what to
optimize w/o outstanding profiler.

> > 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.

Let's think of numbers a bit. The most-inner loop does actual rendering. It
renders 64000 pixels (or more in higher gfx resolutions). Do you think 64000 is
a small number? How about 640*480=307200? The more efficient inner loop the
better performance. But I'm not talking about most-inner loop only. I ouptimize
other loops as well. There is a loop through all Y values from the top of the
screen to the bottom. It includes the most inner loop I mentioned. This loop is
executed 200 times in 320x200, 480 times in 640x480 and so on. I optimize it
too. But again I'm not saying it's enough. I take care about other subroutines.
Scan_Edge also processes polygons and it's also slow. So I optimze it as well.

> The profiler is the proper tool to judge that.

I believe it's true. I have nothing against profiler itself.

> IMHO, you should look at the code produced by GCC more often, to put
> this into a proper perspective.

For sure, I'll do. :)

bye.
Alexei A. Frounze
-----------------------------------------
Homepage: http://alexfru.chat.ru
Mirror:   http://members.xoom.com/alexfru

- Raw text -


  webmaster     delorie software   privacy  
  Copyright 2019   by DJ Delorie     Updated Jul 2019