Date: Thu, 4 Dec 2025 12:06:41 +0100
czw., 4 gru 2025 o 06:23 Kamalesh Lakkampally via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> Hello everyone,
>
> All of the messages I sent were written by me personally. I did not use an LLM to generate the content. I typed everything myself, in plain English, doing my best to explain the concept in detail with headlines and with paragraph style.
>
> Thank you for the detailed questions and discussions. Let me clarify the concept more precisely in terms of the C++ abstract machine, because several responses show that my original message was unclear.
>
> 1. What are “fetch-only operations” conceptually?
>
> They are sequencing operations, not computations.
> A fetch-only operation does not:
>
> load from memory
>
> store to memory
>
> execute user code
>
> allocate resources
>
> produce side effects
>
I would disagree that it is not producing "side effects". It changes
the state of the CPU and that it is detectable.
Whole point of it is to have faster code, right?
Only when considering an abstract machine does that operation do not
it have effects as speed is more of a concern for compiler than
abstract machine.
And this would be prefered to ask the compiler to try to add prefechs
to speed code up? This could be hinted at by the `[[prefech]]`
attribute.
> Instead, it carries a piece of metadata describing what should execute next(i.e where control goes) , and the evaluation order is adjusted accordingly.
>
> 2. What problem does this solve?
>
> In event-driven execution models (e.g., hardware simulators or fine-grained task schedulers), programs often end up in patterns like:
>
> dispatcher();
> → T1();
> → dispatcher();
> → T2();
> → dispatcher();
> → T3();
> ...
>
> The intent is simply:
>
> T1 → T2 → T3 → …
>
>
> but the actual control flow repeatedly returns through the dispatcher, causing excessive sequencing overhead. --> I would be very interested in hearing what existing C++ techniques the committee considers suitable to express this kind of dynamic sequencing without repeatedly returning through a dispatcher.
>
>
> 3. Before / After example (as requested)
>
> Today:
>
> void scheduler() {
>
> while (!q.empty()) {
> auto t = q.pop_front();
> t(); // call and return repeatedly
> }
> }
>
>
> Abstract machine control-flow:
>
> scheduler → T1 → scheduler → T2 → scheduler → T3 → …
>
>
> With fetch-only sequencing operations:
>
> fetch_schedule(q); // purely sequencing metadata
>
> execute_scheduled(); // walks metadata in-order
>
> ...
<std-proposals_at_[hidden]> napisał(a):
>
> Hello everyone,
>
> All of the messages I sent were written by me personally. I did not use an LLM to generate the content. I typed everything myself, in plain English, doing my best to explain the concept in detail with headlines and with paragraph style.
>
> Thank you for the detailed questions and discussions. Let me clarify the concept more precisely in terms of the C++ abstract machine, because several responses show that my original message was unclear.
>
> 1. What are “fetch-only operations” conceptually?
>
> They are sequencing operations, not computations.
> A fetch-only operation does not:
>
> load from memory
>
> store to memory
>
> execute user code
>
> allocate resources
>
> produce side effects
>
I would disagree that it is not producing "side effects". It changes
the state of the CPU and that it is detectable.
Whole point of it is to have faster code, right?
Only when considering an abstract machine does that operation do not
it have effects as speed is more of a concern for compiler than
abstract machine.
And this would be prefered to ask the compiler to try to add prefechs
to speed code up? This could be hinted at by the `[[prefech]]`
attribute.
> Instead, it carries a piece of metadata describing what should execute next(i.e where control goes) , and the evaluation order is adjusted accordingly.
>
> 2. What problem does this solve?
>
> In event-driven execution models (e.g., hardware simulators or fine-grained task schedulers), programs often end up in patterns like:
>
> dispatcher();
> → T1();
> → dispatcher();
> → T2();
> → dispatcher();
> → T3();
> ...
>
> The intent is simply:
>
> T1 → T2 → T3 → …
>
>
> but the actual control flow repeatedly returns through the dispatcher, causing excessive sequencing overhead. --> I would be very interested in hearing what existing C++ techniques the committee considers suitable to express this kind of dynamic sequencing without repeatedly returning through a dispatcher.
>
>
> 3. Before / After example (as requested)
>
> Today:
>
> void scheduler() {
>
> while (!q.empty()) {
> auto t = q.pop_front();
> t(); // call and return repeatedly
> }
> }
>
>
> Abstract machine control-flow:
>
> scheduler → T1 → scheduler → T2 → scheduler → T3 → …
>
>
> With fetch-only sequencing operations:
>
> fetch_schedule(q); // purely sequencing metadata
>
> execute_scheduled(); // walks metadata in-order
>
> ...
Received on 2025-12-04 11:06:54
