std::vector vs Vc::Memory

[Matthias Kretz]

On Monday 10 March 2014 08:43:35 Tijskens Engelbert wrote:
> looking back I guess i was just lucky with the alignment. it was my
> understanding that Vc::Allocator automatically adjusts allocation to the
> vector width one is compiling for - but this is apparently incorrect. 

Vc::Allocator works independent of the rest of the Vc classes. Otherwise it 
wouldn't work for types with alignment requirements higher than the Vc types. 
But, maybe I should simply make Vc::Allocator<T> use the maximum of the 
current SIMD alignment and the alignment requirements of T.

http://code.compeng.uni-frankfurt.de/issues/616

If anyone feels like giving this a shot before I come around to it, feel free! 
(I'm traveling this week and have to prepare talks...)

> Finally, i am still a bit stuck with my question on how to allow for
> dynamic arrays which are compliant with SIMD processing.

float *data = Vc::malloc<float, Vc::AlignOnVector>(number_of_elements);

> Ideally, SIMD
> processing should be done in low level  routines, where as the organisation
> of the computations is done at a higher level which should be unaware of
> SIMD requirements (except for aligned allocation which should be hidden for
> the high level developer) 

In my experience this approach only works for few projects. If you want to do 
a scalable SIMD implementation you normally have to use horizontal 
vectorization. This means your SIMD vectors span over the same entry of N 
objects. Thus, instead of
Point { float x, y, z; };
you work with
PointV { float_v x, y, z; };

(In a future C++ standard I hope it'll be possible that Vc::Vector<Point> is 
equivalent to the above PointV type.)

Thus all your data types and containers store SIMD types all throughout the 
program. But, your algorithms still look mostly the same. Only that the code 
now operates on several objects in parallel.

Cheers,
	Matthias

-- 
─────────────────────────────────────────────────────────────
 Dipl.-Phys. Matthias Kretz

 Web:   http://compeng.uni-frankfurt.de/?mkretz

 SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc
─────────────────────────────────────────────────────────────
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://compeng.uni-frankfurt.de/pipermail/vc/attachments/20140310/de574b0b/attachment.pgp>