Date: Wed, 9 Oct 2019 00:00:51 +0200
On Tue, Oct 8, 2019 at 8:36 PM Ben Craig via SG14 <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
>
>
>
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) 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 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...
- do you also have any binary-size comparisons?
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
>
>
>
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) 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 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...
- do you also have any binary-size comparisons?
-- Domagoj Šarić Tech lead C++ engineer Microblink LTD www.microblink.com <https://microblink.com/> <https://microblink.com/>
Received on 2019-10-08 17:03:17