Date: Mon, 2 Jun 2025 16:50:01 +0000
Perfect!
获取Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Simon Schröder via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, June 3, 2025 12:43:43 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Simon Schröder <dr.simon.schroeder_at_[hidden]>
Subject: Re: [std-proposals] 回复: 回复: 回复: A Proposal about A New Keyword assure
> On Jun 2, 2025, at 11:28 AM, Peter Bindels via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> It has the same code bloat that templates has - arguably more, in case you have multiple assurements that not all are used - and it's a language addition that usually comes with a very high bar of "this is impossible to do right now without this".
I understood the initial proposal slightly different. Sure, templates or tag dispatching could improve performance of function calls. At the same time they would increase code size. However, I believe the original intent was to have just a single function that can be called/jumped into different places. Only very few examples would actually take advantage of this feature. The example given was: The function has an initial check for the parameter range. If the caller can ensure that the argument always returns false for the check, we could (in theory) call the function just after the check. The restriction is that there can‘t be any other code before the check inside the called function (or the compiler can figure out how to rearrange the code without changing the functionality).
Advantages:
1. Just code for a single function. No duplicate (compiled) code for different restricted parameters. Less code in the cache! (And thus better performance?)
2. Avoid/skip over the check. Might not be really relevant because of branch prediction unless we have a weird pattern. (How often does start get called with a negative number? Almost never -> branch predictor is always right.) But, back to 1: Less code in the cache and thus fewer branch predictions for the branch predictor to store.
Challenges:
1. Annotate possible restrictions on parameters in function declarations that could provide a performance improvement. (Using assume(…) on the caller site should tell the compiler everything it needs to know for the call. No extra keyword needed on the side of the caller.)
2. The calling translation unit and the called translation unit need to communicate to the linker how to bring the two together. In the case of a single function with multiple entry points I am not sure if there is an existing feature in linkers that can be used. (Wasn‘t there a C++ talk last year about misunderstood coding guidelines/style guides? Wasn‘t one of the rules originally meant to say that multiple entry points into a function is bad practice? Is that alright in the case of the compiler proving that the optimization is correct? Are there problems with debugging such a function?)
I hope that I haven’t misrepresented the original intent of this proposal.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]cpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
获取Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Simon Schröder via Std-Proposals <std-proposals_at_[hidden]>
Sent: Tuesday, June 3, 2025 12:43:43 AM
To: std-proposals_at_[hidden] <std-proposals_at_[hidden]>
Cc: Simon Schröder <dr.simon.schroeder_at_[hidden]>
Subject: Re: [std-proposals] 回复: 回复: 回复: A Proposal about A New Keyword assure
> On Jun 2, 2025, at 11:28 AM, Peter Bindels via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> It has the same code bloat that templates has - arguably more, in case you have multiple assurements that not all are used - and it's a language addition that usually comes with a very high bar of "this is impossible to do right now without this".
I understood the initial proposal slightly different. Sure, templates or tag dispatching could improve performance of function calls. At the same time they would increase code size. However, I believe the original intent was to have just a single function that can be called/jumped into different places. Only very few examples would actually take advantage of this feature. The example given was: The function has an initial check for the parameter range. If the caller can ensure that the argument always returns false for the check, we could (in theory) call the function just after the check. The restriction is that there can‘t be any other code before the check inside the called function (or the compiler can figure out how to rearrange the code without changing the functionality).
Advantages:
1. Just code for a single function. No duplicate (compiled) code for different restricted parameters. Less code in the cache! (And thus better performance?)
2. Avoid/skip over the check. Might not be really relevant because of branch prediction unless we have a weird pattern. (How often does start get called with a negative number? Almost never -> branch predictor is always right.) But, back to 1: Less code in the cache and thus fewer branch predictions for the branch predictor to store.
Challenges:
1. Annotate possible restrictions on parameters in function declarations that could provide a performance improvement. (Using assume(…) on the caller site should tell the compiler everything it needs to know for the call. No extra keyword needed on the side of the caller.)
2. The calling translation unit and the called translation unit need to communicate to the linker how to bring the two together. In the case of a single function with multiple entry points I am not sure if there is an existing feature in linkers that can be used. (Wasn‘t there a C++ talk last year about misunderstood coding guidelines/style guides? Wasn‘t one of the rules originally meant to say that multiple entry points into a function is bad practice? Is that alright in the case of the compiler proving that the optimization is correct? Are there problems with debugging such a function?)
I hope that I haven’t misrepresented the original intent of this proposal.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]cpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-06-02 16:50:08