Message-ID: <38FAC36B.DD34F8C9@mtu-net.ru> Date: Mon, 17 Apr 2000 11:55:23 +0400 From: "Alexei A. Frounze" X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en,ru MIME-Version: 1.0 To: Eli Zaretskii , djgpp AT delorie DOT com Subject: Re: inefficiency of GCC output code & -O problem References: Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit 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