Mail Archives: djgpp/2000/04/17/05:51:00
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 -