[LAD] vectorization

Jens M Andreasen jens.andreasen at comhem.se
Thu Feb 7 22:50:38 UTC 2008


On Thu, 2008-02-07 at 21:57 +0000, Christian Schoenebeck wrote:
> Am Donnerstag, 7. Februar 2008 19:42:46 schrieb Jens M Andreasen:
> > http://en.wikipedia.org/wiki/SSE4
> 
> 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 at lists.linuxaudio.org
> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
-- 




More information about the Linux-audio-dev mailing list