I just posted my Lenexa ISO C++ trip report over on isocpp.org covering our recent meeting.
The ISO C++ committee is shipping more work sooner via concurrent Technical Specifications, but it’s still fairly new to find ourselves doing so much work that the “new normal” is to issue an international ballot from every ISO C++ meeting. This time, we completed three Technical Specifications (Transactional Memory, Library Fundamentals, and Parallelism) and sent out another for its comment ballot (Concurrency). We also did quite a bit of forward-looking planning for C++17, which is much closer than one would think since we’re aiming for a comment draft in mid/late 2016.
And check out the CppCon angle… it’s great to see the committee/community interaction and collaboration, and I can’t wait for CppCon in September and the fall ISO C++ meeting in October.
Sutter’s Mill 
SIMD types is a very bad idea. Use of such types locks the code into a particular style of vectorization, making it less (performance) portable.
It’s much better to add bits of language to allow the user to tell the compiler what is safe and/or profitable. For pointer-heavy code, a directive to tell the compiler to ignore potential data dependencies is very helpful (in addition, insert request for something like “restrict,” but better, here).
Compilers have all kinds of transformations to improve cache usage, rework loops for better parallel efficiency, etc. Do not constrain the compiler by forcing it to vectorize a particular loop in a particular way. Tell the compiler what is safe and hint at what is profitable and let it do it’s work. It’s the compiler’s job to map to hardware, not the user’s.
The original Intel paper on this cited cache utilization as a motivating example, with the valarray “operate on all elements in one operation before doing the next” semantics being blamed. Fortran array syntax has similar semantics and vectorizing compilers have got along with it just fine. C++’s real handicap with respect to parallelization is ambiguous pointers. Providing tools to eliminate that problem will go a long way toward improving parallelization.
When will be the new SG14 mailing list made publicly available through isocpp.org forum links?