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]>
wrote:

>
> 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?
>
>
> --
> Domagoj Šarić
> Tech lead
> C++ engineer
>
> Microblink LTD
> www.microblink.com <https://microblink.com/>
> <https://microblink.com/>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>