Adding partitioned_vector SPMD example

[hkaiser]

No description provided.

[hkaiser]

[07:33] heller: hkaiser: #1972 looks fine so far. three remarks/questions: 1) The view could act as a container/range so we don't need the begin()/end() 2) There is probably no way to have some form of synchronization within a SPMD algorithm directly 3) SPMD style initialization could be handled within distribution policies. I guess all answers are "yes"?
[07:34] hkaiser: 1) how so, 2) yes, and 3) perhaps
[07:34] hkaiser: SPMD style initialization requires global consistency which I don't know how to ensure
[07:35] hkaiser: (except for implementing PAXOS or similar)
[07:35] heller: well, the distribution policy would require some form of negotiation or so
[07:35] hkaiser: well, the question is whether this would be faster than the initialization from a root locality
[07:36] hkaiser: heller: wrt 1) even if the view is used as a container it still need to have begin/end, why wouldn't it?
[07:37] heller: just for convenience
[07:37] hkaiser: even the container algos rely on begin/end being available underneath
[07:37] heller: well sure, just a matter of user facing API
[07:37] heller: i didn't mean to remove begin()/end() from the view
[07:38] hkaiser: ahh, ok - then you're right
[07:38] heller: just a matter of how you call the parallel algorithm
[07:38] hkaiser: nod
[07:38] heller: 2) is a little concerning
[07:38] hkaiser: any ideas are welcome
[07:39] hkaiser: in my book the idea of spmd relies on explicit synchronization between the localities
[07:39] hkaiser: so no surprises here
[07:39] heller: for 3), yes, we have to do benchmarks. The only case where it is definetly faster is when you you have fixed sized partitions and fixed number of partitions per locality
[07:40] hkaiser: you still need a global negotiation for this
[07:40] heller: or command line parameter
[07:40] heller: or something like that
[07:41] hkaiser: come on, I thought we were over this
[07:42] heller: so the explicit synchronization, once you have a algorithm that requires some for of reduction, or similar, you are essentially required to do everything from locality zero (which wouldn't scale) or implement something around it
[07:42] heller: were we?
[07:42] hkaiser: heller: you'd have to use some explicit reduction which would scale as good as the reduction is implemented
[07:42] heller: yes sure
[07:43] heller: lots of work and experimentation left to do, that's all I wanted to say
[07:43] hkaiser: sure, no doubt
[07:43] hkaiser: I'll merge it as it is, it's useful on its own
[07:44] heller: no doubt
[07:44] heller: it's a good start