Thorsten Froehlich <tho### [at] trfde> wrote:
> clipka wrote:
> > Don't expect all these to be "naive hardware implementation" in the same sense
> > as, say, an integer addition, shift, bit-wise AND/OR/XOR or whatever.

> Exactly that is why you ought to be looking at the SSE2/3 floating-point 
> registers and associated hardware support. The x87 FPU is only there for 
> legacy support and rather inefficient.

  Unless I'm mistaken, the way SSE works, it's a bit difficult to use it
from portable C/C++ directly.

  Any decent C/C++ compiler will be directly able to use the FPU with any
floating point arithmetic you have written in your code. (Of course there's
a lot of optimization that can be done in order to use the FPU stack more
efficiently, but in principle making C/C++ code use the FPU is a relatively
trivial thing for a compiler to do.)

  However, using SSE efficiently is a lot more complicated. Unless I'm
mistaken, unlike with the FPU, there's no direct C/C++ FP -> SSE algorithm
which would work well in all cases. Modern compilers do already have SSE
optimization support, but AFAIK it's rather limited.

  If you are only going to use SSE as a direct substitute for the FPU,
I assume that would be possible, but you probably won't get any significant
speed benefit (perhaps even the contrary). In order to truely get benefit
from SSE, you need to vectorize the calculations so that you can calculate
many things in parallel. This is extremely hard, if not impossible for a
compiler to do with random C/C++ code.

  And even if you knew perfectly what you were doing and how you want your
code to be SSE-vectorized, there's no portable way of expressing that. The
only thing you can do is to try to write code in such way that some compiler
might be able to SSE-vectorize it when enough optimizations have been turned
on. And even then there's just only so much you can do.

-- 
                                                          - Warp

Post a reply to this message