Always operating on just the first two elements of a 4-sized vector

[Matthias Kretz]

Hi Georgios,

On Thursday 06 March 2014 12:05:18 Georgios Bitzes wrote:
> Regarding your proposed workarounds, unfortunately the first solution is
> not really feasible in our code. Most of the target code for vectorization
> is inside header files, so it could be that some code in the same
> translation unit needs SSE and some other AVX. Moreover, the need to pass
> vectors around would make this difficult and buggy in practice.

Well, you'd need a major redesign, I guess. And I agree that this doesn't 
sound like a good approach.

> The second solution looks much better - is this already available or should
> we wait until the next release?

I only have capacity to work on Vc 1.0. It was meant as a suggestion what 
would be possible if someone wants to look into it. I'd certainly lend a 
helping hand, though.

Another alternative would be, that you switch to using the development branch 
leading to Vc 1.0. It's not in a state where you can start using it right 
away, but I hope I can do another tech preview release soon. If you feel 
adventurous feel free to jump on 1.0 and help me get it stable.

Cheers,
	Matthias

> On Thu, Mar 6, 2014 at 11:45 AM, Matthias Kretz <
> 
>[please enable javascript to see the address]> wrote:
> > Hi Georgios,
> > 
> > I think I have the perfect solution for that coming up for Vc 1.0. The
> > general
> > idea is to use something like this:
> > 
> > typedef Vc::simd_array<double, 2> double2_v;
> > 
> > The implementation then is smart enough to figure out that - even when
> > compiled for AVX - it should use an SSE register. The double_v type would
> > still be the best for the target (in contrast to best for the problem :)
> > ).
> > 
> > Until then, with Vc 0.7, you can only work around this by using a
> > different
> > translation unit for where you want to use SSE. Compile with -DVC_IMPL=SSE
> > and
> > Vc::double_v will be Vc::SSE::double_v.
> > BUT, be very careful what this means for the types. All Vc types will be
> > different for differently compiled translation units then. You can only
> > communicate between those via arrays of fundamental types.
> > 
> > If you want to have a better solution sooner than Vc 1.0 there is
> > something
> > you could do for Vc 0.8. In principle Vc 0.8 could support declaring all
> > possible Vc implementations in the same translation unit. Then
> > Vc::double_v
> > would still behave as now, but in addition you could explicitly use the
> > Vc::SSE::double_v type. (Of course this reduces portability - but only
> > until
> > Vc 1.0 when you can replace this with the above double2_v.)
> > 
> > Cheers,
> > 
> >         Matthias
> > 
> > --
> > ─────────────────────────────────────────────────────────────
> > 
> >  Dipl.-Phys. Matthias Kretz
> >  
> >  Web:   http://compeng.uni-frankfurt.de/?mkretz
> >  
> >  SIMD easy and portable: http://compeng.uni-frankfurt.de/?vc
> > 
> > ─────────────────────────────────────────────────────────────

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

 Phone: +49 69 798 44110
 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/20140306/ed80ca51/attachment.pgp>