Mail Archives: djgpp/2000/04/17/19:17:02
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.
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 :-)
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...
Best Wishes,
Grendel
Hi, I'm a signature virus. plz set me as your signature and help me spread
:)
- Raw text -