AFAIK the Linux kernel avoids using SSE just like it avoids the using the
x87 FPU.
The kernel's not supposed to be computation-heavy anyways, that's
userspace's job. I'm not convinced that the compiler matters much beyond
"correctness".
Posted Feb 28, 2009 0:15 UTC (Sat) by nix (subscriber, #2304)
[Link]
Some particularly computation-heavy things use SSE or MMX as need be: if
the lumps of data being manipulated are large enough, the save/restore
overhead is worth it.
(The largest such component is md/raid6.)
having two compilers is good
Posted Mar 1, 2009 21:04 UTC (Sun) by mb (subscriber, #50428)
[Link]
> (The largest such component is md/raid6.)
So well, but this is hand-tuned assembly code, right? So I think the type of C compiler still doesn't matter for this...
having two compilers is good
Posted Mar 1, 2009 22:44 UTC (Sun) by nix (subscriber, #2304)
[Link]
Well, yes. The type of compiler only matters if the compiler knows enough
to translate loops directly into SSE instructions. Can any compiler do
that yet?
(I'm ignoring things like GCC's SEE intrinsics here, as they're only
useful if you only want a few of them: they're just too ugly to maintain
otherwise. I've seen codebases with hundreds of intrinsics in a row, and
they are *always* clearer when translated into a .S instead.)
having two compilers is good
Posted Mar 1, 2009 23:49 UTC (Sun) by nix (subscriber, #2304)
[Link]
Obviously when I said 'SEE' there I meant 'SSE'. GCC hasn't defined a
whole new bizarrely-named instruction set of its very own. ;)
having two compilers is good
Posted Mar 2, 2009 8:03 UTC (Mon) by joib (guest, #8541)
[Link]
Well, most production quality compilers, gcc included, are capable of vectorization these days. For gcc there is the -ftree-vectorize option (included in -O3 in newer versions), and -ftree-vectorizer-verbose= option for printing diagnostics.
For C and C++, you probably have to mark some of your argument pointers/references with __restrict.