|
![](/i/fill.gif) |
Daniel Nilsson <pov### [at] daniel-nilsson com> wrote:
> > This can be optimized to:
> > [...]
> > Or maybe this is even a bit faster (and actually a tiny bit more defensively
> > coded):
> > [...]
>
> No need to optimize the code, that's the job of the compiler. Any modern
> compiler will notice the common subexpressions and optimize them. I just
> did a small test with all three versions above compiled with "gcc -S
> -O2" (gcc 4.1.2 on x86_64 linux). The produced assembly is virtually
> identical for all three cases, the last one actually has the most
> instructions generated (extra moves mostly).
Hm... well, maybe I'm showing my age... I'm actually not too deep into
compiler-based optimizations. It has been a while since I last looked at what
an x86 compiler makes of my C/C++ code.
I'd still consider using the last version though, because I know it cannot run
into number precision issues with the sqrt(). But then agan, I'm not a learned
floating-point expert either, so maybe I'm a bit over-defensive here.
(My job is usually to write robust and easy-to-maintain software (or fix less
robust and more-difficult-to-maintain software), with some hardware jockeys
making sure that the small black boxes it is flashed into provide safe margins
of computing power.)
> Oh, and happy new year!
Same to you, and everyone else around.
Post a reply to this message
|
![](/i/fill.gif) |