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_at_[hidden]>
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_at_[hidden]>
> 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_at_[hidden]> 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_at_[hidden]> 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_at_[hidden]
>>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>>>>
>>> _______________________________________________
>>> SG14 mailing list
>>> SG14_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>>>
>> _______________________________________________
>> SG14 mailing list
>> SG14_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>