HI all, I like to start a google doc of the features list that we can all work on based on the call yesterday.  Please wait for that coming. Thanks Steffan.

On Wed, Dec 11, 2019 at 4:26 PM Patrice Roy via SG14 <sg14@lists.isocpp.org> wrote:
During the SG14 meeting, I was with a friend from one of the major game companies in Montréal, and he provided me with an interesting list. It will take me a few days to organize something but I'll publish it here soon.

Le mer. 11 déc. 2019 à 16:24, Jeremy Ong via SG14 <sg14@lists.isocpp.org> a écrit :
This is a bit out of left field, but I'd be interested in a data structure adapter which packs its elements based on Morton codes (or some other space-filling Hilbert curve, see https://en.wikipedia.org/wiki/Z-order_curve).

The idea is that there are a good chunk of algorithms that operate on densely packed structures where the likelihood of accessing neighboring elements is high. Examples I can think of off the top of my head:
1. Simulating a fluid or crowd motion
2. Any finite element model (e.g. simulating cloth)
3. Lattice computation (e.g. Lattice quantum chromodynamics)
4. Sampling neighboring points in an image, possibly for the purposes of compression or filtering
5. A painting application (e.g. flood fill, drawing a continuous stroke/curve to a raster).
6. Accelerating a matrix multiplication by parallelizing the computation on minors.

The last application perhaps best captures the "gist" of why this is useful. If I want to parallelize my computation, I need to partition the data in contiguous chunks. Otherwise, each thread or worker will ultimately be accessing essentially random addresses within the data range. Aside from memory coherency issues, this would cause issues with false sharing if my data is not padded to the size of a cache line.

This technique is widely used already in GPUs. For example, when uploading a texture for sampling later on, if the texture isn't already block-compressed, the GPU will swizzle the texture such that sampling is efficient. For the purposes of bilinear filtering, neighboring pixels will fetch 4 texels in the texture that will all likely reside in the texture cache. If not, they generally can be populated in the cache with a single cache-line load (as opposed to four).

This could be implemented in user-land (e.g. `std::nd_array<typename T, size_t...>` ignore the bad name for the time-being) in an arbitrary number of dimensions. The tradeoff is that single element access will require several cycles to compute the address (a few bit operations).

Does this warrant inclusion in the standard? This is actually something not 100% clear to me but I'd be interested in other people's thoughts.

On Wed, Dec 11, 2019 at 1:45 PM Matthew Butler via SG14 <sg14@lists.isocpp.org> wrote:
I would be interested in hearing everyone's thoughts on Herbceptions.

Also Colony and Ring Buffer would be useful adds.

On Wed, Dec 11, 2019 at 1:41 PM Tjernstrom, Staffan via SG14 <sg14@lists.isocpp.org> wrote:

Today's call discussed informally which features we would like to pursue as a group for '23 and beyond. Many suggestions appeared both in the chat as well as in the call itself.

 

Feel free to use this thread as a collection point that we can circle back around to and gather inspiration from.

 

Kind Rgds

Staffan Tj.

 




IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
_______________________________________________
SG14 mailing list
SG14@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14
_______________________________________________
SG14 mailing list
SG14@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14
_______________________________________________
SG14 mailing list
SG14@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14
_______________________________________________
SG14 mailing list
SG14@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg14