Date: Wed, 9 Oct 2019 02:38:54 +0000
I'm pretty sure about my non-trivial vs. trivial numbers. Here's an older set of runs that I had in a draft version of the paper:
https://raw.githack.com/ben-craig/error_bench/f24c0c1e9e133b68b548f1a6265de7adf8a43f59/error_speed.html#happy_write_to_a_global_histogram
You can see that the general shape of the graph is the same, but the means and medians are slightly different.
Take a look at the difference in assembly between trivial and non-trivial with the version of gcc I used:
https://godbolt.org/z/CPgHg6
The general idea is that a local destructor really makes moving things in registers miserable. You get things in registers, but you immediately need to move them somewhere else because the destructor you are about to call would clobber those values. Then you have to move them back so that you can return them. If you have a non-trivial object, then it gets RVO'd on the stack, and you can just pass that pointer along, and there's very little shuffling of registers or data. Lots of code will need to read that top element of the stack to check if it is an error, but that value is going to be super hot in the cache.
I chose not to use any likely / unlikely annotations, largely because MSVC doesn't support them. This is a shame, because there were a few performance anomalies that I would have liked to investigated by throwing annotations at the problem.
Size benchmarks are in this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1640r0.html. An R1 will be in the mailing with substantially _less_ information, as the quantity of data in R0 caused some confusion.
________________________________
From: SG14 <sg14-bounces_at_[hidden]> on behalf of Michael Wong via SG14 <sg14_at_[hidden]>
Sent: Tuesday, October 8, 2019 8:37 PM
To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]>
Cc: Michael Wong <fraggamuffin_at_[hidden]>
Subject: [EXTERNAL] Re: [SG14] Call tomorrow Wednesday Oct 16 2-4 ET
Hi all looks like we can discuss the Error speed benchmark results. I will set an agenda. Thank you. Regards
On Tue, Oct 8, 2019 at 6:11 PM Domagoj Šarić via SG14 <sg14_at_[hidden]<mailto:sg14_at_[hidden]>> wrote:
On Tue, Oct 8, 2019 at 8:36 PM Ben Craig via SG14 <sg14_at_[hidden]<mailto:sg14_at_[hidden]>> wrote:
P1866R0: Error speed benchmarking is ready if people want to talk about that.
https://raw.githack.com/ben-craig/error_bench/master/error_speed.html<https://urldefense.com/v3/__https://raw.githack.com/ben-craig/error_bench/master/error_speed.html__;!fqWJcnlTkjM!8vl80xQ42m8gerr4VireZISRKkP8CdMS5wklcMsvO0tWedntu5N783ujn62E$>
Hi Ben, took a look at the link above:
- the difference between results you got for return_struct and return_nt_struct really surprised me - I'd expect exactly the opposite result (based on my experience from some time ago when I examined EH related, MSVC only, codegen/overhead with some frequency and care) or at best no difference with Clang and GCC - because I've seen presence of non trivially destructible objects (as locals or as by-val function parameters) completely trip up MSVC (I think 2015 was the last version where I checked this) even without any throwing code - simply the presence of objects that would need to be cleaned up caused it to go into 'EH mode' so to speak (and e.g. failing to inline trivial functions simply because they had a by-val parameter with a non trivial destructor)....TL;DR could you re check that particular result?
- could you 'help' & rebenchmark the error code versions happy path with (un)likely branching attributes/hints - some time ago I also wrote a yet-another expected/outcome-like library (before knowing about these other proposals:) which was and still is unique WRT all the other proposals as it offers a solution as close as possible to 'herbceptions' (it enables library writers to provide a single API, i.e. w/o separate error_code overloads, that automatically reports errors with exceptions or error-codes based on how the _user_ uses/calls it, http://boost.2283326.n4.nabble.com/err-RFC-td4681600.html<https://urldefense.com/v3/__http://boost.2283326.n4.nabble.com/err-RFC-td4681600.html__;!fqWJcnlTkjM!8vl80xQ42m8gerr4VireZISRKkP8CdMS5wklcMsvO0tWedntu5N78yFvm4ff$>) with a pure library approach and saw Clang produce better codegen when I 'sprinkled' the library with the (un)likely hints (i.e. hinting/assuming that the error path is the unlikely/sad path) - it can be seen https://gist.github.com/psiha/f92a7b8a93c5ce1736ae<https://urldefense.com/v3/__https://gist.github.com/psiha/f92a7b8a93c5ce1736ae__;!fqWJcnlTkjM!8vl80xQ42m8gerr4VireZISRKkP8CdMS5wklcMsvO0tWedntu5N78wnCfGBl$> how the error path is placed in the 'colder' section at the end of the function instead of being interleaved with the 'happy path', fwiw the source for that codegen is https://gist.github.com/psiha/c0823fefc01fa3b39662.<https://urldefense.com/v3/__https://gist.github.com/psiha/c0823fefc01fa3b39662.__;!fqWJcnlTkjM!8vl80xQ42m8gerr4VireZISRKkP8CdMS5wklcMsvO0tWedntu5N783iQlomN$>..
- do you also have any binary-size comparisons?
https://raw.githack.com/ben-craig/error_bench/f24c0c1e9e133b68b548f1a6265de7adf8a43f59/error_speed.html#happy_write_to_a_global_histogram
You can see that the general shape of the graph is the same, but the means and medians are slightly different.
Take a look at the difference in assembly between trivial and non-trivial with the version of gcc I used:
https://godbolt.org/z/CPgHg6
The general idea is that a local destructor really makes moving things in registers miserable. You get things in registers, but you immediately need to move them somewhere else because the destructor you are about to call would clobber those values. Then you have to move them back so that you can return them. If you have a non-trivial object, then it gets RVO'd on the stack, and you can just pass that pointer along, and there's very little shuffling of registers or data. Lots of code will need to read that top element of the stack to check if it is an error, but that value is going to be super hot in the cache.
I chose not to use any likely / unlikely annotations, largely because MSVC doesn't support them. This is a shame, because there were a few performance anomalies that I would have liked to investigated by throwing annotations at the problem.
Size benchmarks are in this paper: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1640r0.html. An R1 will be in the mailing with substantially _less_ information, as the quantity of data in R0 caused some confusion.
________________________________
From: SG14 <sg14-bounces_at_[hidden]> on behalf of Michael Wong via SG14 <sg14_at_[hidden]>
Sent: Tuesday, October 8, 2019 8:37 PM
To: Low Latency:Game Dev/Financial/Trading/Simulation/Embedded Devices <sg14_at_[hidden]>
Cc: Michael Wong <fraggamuffin_at_[hidden]>
Subject: [EXTERNAL] Re: [SG14] Call tomorrow Wednesday Oct 16 2-4 ET
Hi all looks like we can discuss the Error speed benchmark results. I will set an agenda. Thank you. Regards
On Tue, Oct 8, 2019 at 6:11 PM Domagoj Šarić via SG14 <sg14_at_[hidden]<mailto:sg14_at_[hidden]>> wrote:
On Tue, Oct 8, 2019 at 8:36 PM Ben Craig via SG14 <sg14_at_[hidden]<mailto:sg14_at_[hidden]>> wrote:
P1866R0: Error speed benchmarking is ready if people want to talk about that.
https://raw.githack.com/ben-craig/error_bench/master/error_speed.html<https://urldefense.com/v3/__https://raw.githack.com/ben-craig/error_bench/master/error_speed.html__;!fqWJcnlTkjM!8vl80xQ42m8gerr4VireZISRKkP8CdMS5wklcMsvO0tWedntu5N783ujn62E$>
Hi Ben, took a look at the link above:
- the difference between results you got for return_struct and return_nt_struct really surprised me - I'd expect exactly the opposite result (based on my experience from some time ago when I examined EH related, MSVC only, codegen/overhead with some frequency and care) or at best no difference with Clang and GCC - because I've seen presence of non trivially destructible objects (as locals or as by-val function parameters) completely trip up MSVC (I think 2015 was the last version where I checked this) even without any throwing code - simply the presence of objects that would need to be cleaned up caused it to go into 'EH mode' so to speak (and e.g. failing to inline trivial functions simply because they had a by-val parameter with a non trivial destructor)....TL;DR could you re check that particular result?
- could you 'help' & rebenchmark the error code versions happy path with (un)likely branching attributes/hints - some time ago I also wrote a yet-another expected/outcome-like library (before knowing about these other proposals:) which was and still is unique WRT all the other proposals as it offers a solution as close as possible to 'herbceptions' (it enables library writers to provide a single API, i.e. w/o separate error_code overloads, that automatically reports errors with exceptions or error-codes based on how the _user_ uses/calls it, http://boost.2283326.n4.nabble.com/err-RFC-td4681600.html<https://urldefense.com/v3/__http://boost.2283326.n4.nabble.com/err-RFC-td4681600.html__;!fqWJcnlTkjM!8vl80xQ42m8gerr4VireZISRKkP8CdMS5wklcMsvO0tWedntu5N78yFvm4ff$>) with a pure library approach and saw Clang produce better codegen when I 'sprinkled' the library with the (un)likely hints (i.e. hinting/assuming that the error path is the unlikely/sad path) - it can be seen https://gist.github.com/psiha/f92a7b8a93c5ce1736ae<https://urldefense.com/v3/__https://gist.github.com/psiha/f92a7b8a93c5ce1736ae__;!fqWJcnlTkjM!8vl80xQ42m8gerr4VireZISRKkP8CdMS5wklcMsvO0tWedntu5N78wnCfGBl$> how the error path is placed in the 'colder' section at the end of the function instead of being interleaved with the 'happy path', fwiw the source for that codegen is https://gist.github.com/psiha/c0823fefc01fa3b39662.<https://urldefense.com/v3/__https://gist.github.com/psiha/c0823fefc01fa3b39662.__;!fqWJcnlTkjM!8vl80xQ42m8gerr4VireZISRKkP8CdMS5wklcMsvO0tWedntu5N783iQlomN$>..
- do you also have any binary-size comparisons?
-- Domagoj Šarić Tech lead C++ engineer Microblink LTD www.microblink.com<https://urldefense.com/v3/__https://microblink.com/__;!fqWJcnlTkjM!8vl80xQ42m8gerr4VireZISRKkP8CdMS5wklcMsvO0tWedntu5N780LH5y8W$> [http://apps.microblink.com/img/email/microblink-logo.png]<https://urldefense.com/v3/__https://microblink.com/__;!fqWJcnlTkjM!8vl80xQ42m8gerr4VireZISRKkP8CdMS5wklcMsvO0tWedntu5N780LH5y8W$> _______________________________________________ SG14 mailing list SG14_at_[hidden]<mailto:SG14_at_[hidden]> https://lists.isocpp.org/mailman/listinfo.cgi/sg14<https://urldefense.com/v3/__https://lists.isocpp.org/mailman/listinfo.cgi/sg14__;!fqWJcnlTkjM!8vl80xQ42m8gerr4VireZISRKkP8CdMS5wklcMsvO0tWedntu5N78zwbP2dg$>
Received on 2019-10-08 21:41:09