Thanks for replying-

On 6/08/2019 9:06 PM, Niall Douglas via SG14 wrote:
>> Granted - but I think this is off-topic. By a significant degree-
>> I'd be quite interested in a proposal of the type you're describing,
>> particularly one that did a good job of explaining the "what, where and
>> why" to slum-dog programmers, such as myself ;)
>
> A prerequisite is P1031 Low level file i/o, or some other virtual memory
> and page fault management layer. So there is no rush in bringing these
> to the committee, given that they are unimplementable in standard C++
> currently.

Granted - I guess that makes it pointless to ask for those kinds of
proposals from others, too?


>> But in terms of my stuff, can we focus on whether or not SIMD is (a)
>> worth focussing on (this talk suggests it is:
>> https://www.youtube.com/watch?v=8khWb-Bhhvs), (B) whether gather-scatter
>> SIMD is currently worth the time on most modern hardware and
>
> For anything exceeding tight loops of a few hundred opcodes, SIMD is
> usually worth it. *IF* you can lay out your data for SIMD. Often
> repacking the data layout exceeds the gain from SIMD, it's very
> frustrating at times.

This was my suspicion. Unfortunately I lack anything with AVX512 but I
might try to benchmark it with AVX2, despite it's lackluster gather
performance.


> (C) whether
>> I should be exposing the internals of my container.
>
> That's the same debate as the intrusive-vs-not container debate. There
> is no one answer, it "depends".

I guess it is in the sense that the user can mess with the validity of
the container if they choose to - although the ability to 'mess with'
would be greatly heightened in this case. The user could fundamentally
mess with the validity of the container via the data accessed, whereas
with intrusive containers generally they can only mess with the validity
of the secondary container (the intrusive list or whatever) rather than
the primary.