From: "Alexei A. Frounze" Newsgroups: comp.os.msdos.djgpp Subject: Re: inefficiency of GCC output code & -O problem Date: Tue, 18 Apr 2000 05:15:05 +0400 Organization: MTU-Intel ISP Lines: 61 Message-ID: <38FBB719.3915C530@mtu-net.ru> References: NNTP-Posting-Host: ppp97-207.dialup.mtu-net.ru Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: gavrilo.mtu.ru 956020475 31802 212.188.97.207 (18 Apr 2000 01:14:35 GMT) X-Complaints-To: usenet-abuse AT mtu DOT ru NNTP-Posting-Date: 18 Apr 2000 01:14:35 GMT Cc: buers AT gmx DOT de, kalum AT lintux DOT cx X-Mailer: Mozilla 4.72 [en] (Win95; I) X-Accept-Language: en,ru To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Kalum Somaratna aka Grendel wrote: > > On 17 Apr 2000, Dieter Buerssner wrote: > > > > Alexei's code will "cache" some values on the FPU stack, which > > gcc is not able to see (with the switches I used). Nevertheless, > > even here, with the help of only one line of inline assembly, > > it produces comparable results. Again, it would loose, when all > > those references and adress-off operations would be omitted. > > It should be clear, that the compiler won't reach the efficiency > > of hand optimzed assembler code. Whether the relative small > > difference here is worth all the trouble, ... > > This is precicely the point that I was trying to make earlier, A good > optimising compiler can produce code which is as fast/faster as hand > optimised asm. And in this case it did...It upped the frame rate from 70 > from the assembly code to 72 FPS from the C code .....:-) > > So as you can see Alexei writing the code in inline assembly, and adding > all those "tricks" didn't amount to much difference really. Whether > getting a reduction!!! in 2 FPS is worth the pain of coding in assembly > and also the reultatnt decrease in redability of the code is indeed > questionable. You've forgot (in fact, Dieter haven't mentioned) about the FIDIVRL instruction executed in parallel to the span() function. This is a real trick that makes difference. Even Dieter didn't change it and left this piece of my inline ASM AS-IS. With FIDIVRL trick FPS is 45...70, w/o 36...52. Check this yourself or ask Dieter. :) But for sure the rest of my inline code may be replaced with C. > This most often is what happens in the places I work, programmers without > thinking of the speed of C code and also thinking that *they are very > smart*, directly write a routine in assembly generating "hand sloptimized" > code in the process and introducing countless bugs too... > > > Alexei, I have made some fun. I hope I have made up for it, by this > > post, that took actually longer to write, than the coding. > > I will send you the modified source by email. The post hopefully > > was of general interest. > > Yes indeed Dieter, This was of certainly of great interest and we owe > you a big thank you :-) For sure thanks. Two clever heads much better than only one. :) > It once again proved that a good optimising compiler can do a excellent > job...also the wisdom of running a profiler and seing which routines take > up most time... Yes, we have proved. We also haven't trow away all my inline ASM. The FIDIVRL trick is still alive. :) bye. Alexei A. Frounze ----------------------------------------- Homepage: http://alexfru.chat.ru Mirror: http://members.xoom.com/alexfru