7 Feb
2008
7 Feb
'08
6:50 p.m.
On Thu, 2008-02-07 at 21:57 +0000, Christian Schoenebeck wrote:
Am Donnerstag, 7. Februar 2008 19:42:46 schrieb Jens M
Andreasen:
I didn't mean the hardware restriction, that is the limited power of current
SSE instructions. What I meant was the yet (IMO) incomplete implementation of
vector extensions in gcc.
The problem is that Intel's implementation of Vector is a moving target,
with a roadmap which retrospectively reads like as if carbon-copied from
a Brazilian Favela ...
I mean, what is there to complete with gcc when nobody knows where the
underlying hardware is moving? There was a presentation of the ultra low
powered Silverthorne - a processor which could bring us back to silent
computing again - this week at ISSCC, but still nobody knows wether it
will have SSE4.1 like Penryn or if it will be stuck with SSSE3 like
Merom?
Creating pseudo vector instructions, running slower than their scalar
counterparts - the field insert/extraction you was looking for being as
good an example as any - without as much as a promise of support in
future hardware, is a waste of perfectly good processor cycles.
[phew! :-D]
mvh // Jens M Andreasen
I would expect to be able to access the cells of a
vector in C(++) by pure
high level instructions and gcc to compile them to e.g. "workaround" SHUFPS
instruction sequences automatically. But there's no such (or was not such)
high level access support in gcc at all yet. As soon as you want to be able
to do things on element / cell level (e.g. also rotating the vector cells),
you would have to go low level and in this case there's no much sense in
using gcc's vector extensions at all.
CU
Christian
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev(a)lists.linuxaudio.org
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
--