Re: [boost] Reforming Boost.System and <system_error> round 2

Subject: Re: [boost] Reforming Boost.System and <system_error> round 2
From: Richard Hodges (hodges.r_at_[hidden])
Date: 2018-01-16 15:34:31

> If it requires an indirect call to check for success, that's a problem
too.

Any function which would produce an error code will at best be in a
userland library. At worst it will involve a context switch into the
kernel. Can we really claim that the cost of (at worst) a simple indirect
jump actually matters?

However, I suspect this conversation will be fruitless. Too many entrenched
positions and not enough evidence.

Perhaps we should be looking forward.

What is the semantic result of a system call in reality? *Either* error *or*
result (or partial result with error, in the case where we supplied
insufficient buffer space).

Boost.Outcome seems to me to be going in the right direction here. Return a
variant and visit that. No indirection, no if/else, no return values that
contain "valid but unspecified" values. Simple, clean and difficult to
abuse.

On 16 January 2018 at 16:25, Andrey Semashev via Boost <
boost_at_[hidden]> wrote:

> On 01/16/18 17:50, Niall Douglas via Boost wrote:
>
>>
>>> Given the above, unless LTO is used, I think the compiler will most
>>> often not be able to optimize the virtual function call.
>>>
>>
>> As you noticed later in your reply, if a virtual function is marked
>> final, the compiler inserts a check to see if the vtable's
>> implementation matches and if so uses an inlined edition.
>>
>
> Being final has no effect if the final function declaration is not
> immediately visible to the compiler. The compiler optimization that I
> described is performed regardless of that markup.
>
> Do I think this overhead is significant enough? Difficult to tell.
>>> Certainly I'm not happy about it, but I could probably live with the
>>> 1.5x overhead. However, it still results in code bloat and there is no
>>> guarantee this optimization will be performed by the compiler (or that
>>> it will be effective if e.g. my code always overrides
>>> `error_category::failure`). Thing is, every bit of overhead makes me
>>> more and more likely consider dropping `error_code` in favor of direct
>>> use of error codes. `error_code` already carries additional baggage of
>>> the pointer to error category.
>>>
>>
>> You might be interested to learn that in a real world code base I
>> tested, padding error_code's size to 64 bytes produced no statistically
>> observable slowdown on Intel Ivy Bridge. As soon as it tipped over 64
>> bytes though, it became very noticeable, about 5%. That was for
>> error_code_extended in Outcome v1, I wanted to see how much payload I
>> could cram in there.
>>
>> So when you say error_code comes with baggage over C error codes, I'll
>> claim that you could in fact add lots more baggage still and probably
>> see little effect.
>>
>
> Sure, what you call "significant overhead" depends on what you actually
> do. That's why there is no single answer to the question you asked in the
> initial message.
>
> But note that `error_code` is supposed to be the replacement for all kinds
> of error codes in the wild. There are APIs that use error codes with very
> simple, even trivial functions like setters or getters. If we are to claim
> `error_code` is suitable for those cases then it really should be very
> *very* close in costs to a simple `int` to be viable. So if it, for
> instance, cannot fit in a register to return efficiently then that's a
> problem. If it requires an indirect call to check for success, that's a
> problem too.
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman
> /listinfo.cgi/boost
>