I also ran into another use-case that I have for P2300-related
optimisations that I'd like to implement.

In my case, I am exploring whether it's possible to avoid child
operation_state objects from needing to store the receiver
if the child operation_state object is a sub-object of a parent
operation_state object and the receiver simply contains
a pointer to the parent operation_state (a very common situation).

In this case, we can instead just compute the receiver object on-demand by
calculating the address of the parent
operation_state object from the address of the child operation_state object
and can avoid needing to store the receiver
containing the pointer to the parent object.

This may seem a small win on an individual operation level, but if you have
complex sender-compositions where
there might be many-levels-deep nesting of operation-states all allocated
inline in a single top-level operation-state
then this can quickly add up to a saving of many pointer-sized receivers
(plus any additional padding necessary).

Further, when a leaf operation wants to look up some context on the
receiver (e.g. get_stop_token(r)) which then
forwards this query up the chain of parent receivers, this often results in
pointer-chasing.
e.g. one receiver contains a pointer to parent operation-state then loads
next receiver from that operation-state
which then needs to load the next receiver from the next operation-state
etc.
This means calling get_stop_token() on a leaf receiver when the stop-token
is provided 5 levels up will require
5 sequential pointer-dereferences to obtain the stop-token.

If instead, we are able to calculate the address of the parent
operation-state as an offset from the child operation
state then getting the address of the top-level operation-state containing
the stop-token just becomes subtracting
the relative offset of each child-operation in its parent and applying this
successively to get the address of the
top-level operation-state. The compiler can then easily constant-fold these
offsets to reduce it to a single offset
from the leaf operation-state.

Applying this optimisation has the potential to both reduce the size of
operation-state objects, increasing cache
locality, reducing memory pressure, etc, but also to improve performance of
receiver queries by avoiding the
pointer-chasing stack-walk behaviour that composed operations currently
need to do.

For an example see https://godbolt.org/z/nKnYnfv4E

This optimisation relies on the ability to calculate the address of the
parent-object given the address of the sub-object,
however, which is not currently possible to do without invoking undefined
behaviour.

So consider this a +1 from me for adding something like this to the
standard.
Please also feel free to add this as additional motivation for the paper.

Let me know if there is anything I can do to help move this forward.

Cheers,
Lewis.

On Mon, Aug 22, 2022 at 9:07 AM Michael Scire via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> I e-mailed std::proposals about this last year
> (std::parent_of_member/std::containing_object_of_member), and got as far as
> writing a proposal paper, though I got too busy to submit it as a
> P-numbered proposal/etc.
>
> See here:
> https://github.com/SciresM/containing_object_of_member/blob/master/containing_object_of_member.pdf
>
> I am still interested in submitting the above, and it's the same
> fundamental operation you're requesting here.
>
> On Sun, Aug 21, 2022 at 4:23 PM Phil Bouchard via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>>
>> On 8/21/22 19:10, Walt Karas wrote:
>>
>> Yes I'd bet big this technique is an often reinvented wheel.
>>
>> Why do you prefer two static casts involving void * over a reinterpret
>> cast? Also, your C style cast is really a reinterpret cast. I think the
>> reason for having reinterpret cast is that it's a (greppable) warning that
>> something is dangerous. And this technique is fairly dangerous, mistakes
>> can elude static checking.
>>
>> Yeah I just got the habit of not using any reinterpret_casts from the
>> Boost community standards, so it's just another way of writing them down.
>>
>> And I wasn't sure how alignments and little to big endian machines would
>> convert them.
>>
>>
>> Sent from Yahoo Mail on Android
>> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
>>
>> On Sun, Aug 21, 2022 at 4:38 PM, Phil Bouchard via Std-Proposals
>> <std-proposals_at_[hidden]> <std-proposals_at_[hidden]> wrote:
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
>> --
>> [image: Logo] <https://www.fornux.com/>
>> *Phil Bouchard* [image: facebook icon]
>> <https://www.linkedin.com/in/phil-bouchard-5723a910/>
>> CTO
>> T: (819) 328-4743
>> E: phil_at_[hidden] | www.fornux.com
>> 1188 rue Saint-Louis | Gatineau (Qc), J8T 2L8 Canada
>> [image: Banner] <https://goglobalawards.org/> Le message ci-dessus,
>> ainsi que les documents l'accompagnant, sont destinés uniquement aux
>> personnes identifiées et peuvent contenir des informations privilégiées,
>> confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message
>> par erreur, veuillez le détruire.
>> This communication (and/or the attachments) is intended for named
>> recipients only and may contain privileged or confidential information
>> which is not to be disclosed. If you received this communication by mistake
>> please destroy all copies.
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>