Fwd: Questions about Vc

[Daniel Cámpora]

Hi Matthias,

Inline responses.

[please enable javascript to see the address]>:

> Hi Daniel,
>
> answers are inline.
>
> On Tuesday 23 September 2014 17:26:01 David Rohr wrote:
> > -------- Forwarded Message --------
> > Subject:      Questions about Vc
> > Date:         Tue, 23 Sep 2014 12:17:16 +0200
>[please enable javascript to see the address]>
>[please enable javascript to see the address]>
> >
> > First thing first, is there a mailing list? (I can't find it).
>
> The mailing lists are documented here:
> http://code.compeng.uni-frankfurt.de/projects/vc#Communication
>
> Feel free to post these kinds of questions to the list. I think they are of
> wider interest to the community. (And feel free to direct answers to this
> mail
> to the list as well.)
>
>
Cool, added myself and sending this to the list as well, in case someone is
interested.


> > Long story short, this piece of code (SSE):
> >
> > v3 = _mm_shuffle_ps(v1, v1, _MM_SHUFFLE(2,1,2,0));
> >
> > Ie. in Fog's library:
> >
> > av3 = permute4f<0,2,1,2>(av1);
> >
> > Is not portable afaik to vc, unless using concrete SSE bindings.
>
> Yes, and that's the fundamental difference between Vc and most other SIMD
> type
> class wrappers. Vc uses types that have a target-dependent width. I.e. if
> you'd write
>  float_v x = ...;
>  x = permute4f<0,2,1,2>(x);
> what does that mean with Vc::Scalar, Vc::AVX, or Vc::MIC?
>
> > However,
> > /swizzles/ exist...
>
> Yes, and I feel slightly bad about them. They are a half-baked solution
> that I
> more or less inherited from MIC intrinsics.
>
> That all said. I still want to, no, need to have a solution for shuffles
> for
> Vc. But it must be one that facilitates portable code.
>
> Therefore, I would be grateful if you can make a list of use cases where
> vector shuffles are needed. Myself, I have only needed shuffles to
> implement
> some functionality of the Vc functions. But in application code I never
> needed
> it. Reductions fully sufficed for all my SIMD programming. From actual
> real-
> world use cases it is often possible to find the portable abstraction that
> is
> still missing from Vc.
>
>
I do agree you should rely, whenever possible, on an undetermined vector
length
when vectorising your code. That way, you ensure scalability to future
architectures,
and leave the conversion up to the library / compiler.

By having swizzles, you still leave the choice to the programmer to use
shuffle
operations shall he deem them necessary, which if you ask me is a good
thing!

The particular use case I'm dealing with is described in page 18 of the
following presentation,

http://bit.ly/1uVSKTh

If you feel like looking at code, it's here,

http://bit.ly/1vqqQjU

In short, it's a function with RAW dependencies among the different calls.
It's not
possible to vectorise at the loop level, which is what you'd usually do in
SIMD. But
still it's a portion of code with a high number of EX operations, and very
few load / stores.

The reason why I'd like to use swizzles (or similar), is to maintain
portability shall we
go to another architecture in the future.


> > In my honest opinion, relying on letters to shuffle things around seems a
> > bad idea; it's less powerful, more difficult to read, and introduces a
> lot
> > of boilerplate code. In my concrete example, I can't do
> permute4f<0,2,1,2>!
>
> Yeah, like I said this is motivated by the MIC intrinsics and basically
> tries
> to capture actual swizzles. I.e. shuffles that can be executed at no extra
> cost with almost every SIMD instruction.
>
>
I'm still not very familiar with AVX512, but is there a performance impact
by
using swizzles as opposed to shuffles? (Intel intrinsics guide doesn't seem
to have
numbers regarding latencies and CPIs yet).

I must admit I only looked briefly at the header files. Would it be much of
a pain to
expose a templated version of swizzles, ie. with the <x,y,z,w> notation?

Cheers,
Daniel


> > Is there some hidden reason I don't see why this is like it is? :-)
>
> I hope it's not hidden to you any longer. :-)
>
> Cheers,
>         Matthias
>
> --
> ─────────────────────────────────────────────────────────────
>  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
> ─────────────────────────────────────────────────────────────




-- 
Daniel Hugo Cámpora Pérez
European Organization for Nuclear Research (CERN)
PH LBC, LHCb Online Fellow
[please enable javascript to see the address]
tel. intern 166473
tel. +41 (0) 764876473
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://compeng.uni-frankfurt.de/pipermail/vc-devel/attachments/20140929/2d1a24ac/attachment.html>