Re: [boost] [outcome] How to drop the formal empty state

Subject: Re: [boost] [outcome] How to drop the formal empty state
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2017-05-27 12:54:58

>> >> As you'll note, the first possible state (empty) tends to be chosen
>> by >> the compiler as the most likely. That implies a 20 cycle branch
>> >> misprediction cost for each of the valued or errored states. So
>> they >> are equally costly, which is intentional.
>> >
>> > Wait a minute. Are you saying that you consider the fact that valued
>> and > errored are equally slow a feature, instead of one of them being
>> fast? > How is that a good thing? Of course empty should be the least
>> likely - > it _is_ the least likely.
>>
>> As I've mentioned several times already in other threads, that was a
>> deliberate and intentional design choice for outcome/result.
>> Predictable latency throughout.
> 
> That's an intriguing statement.
> 
> Now I know that you usually know what you're talking about, so perhaps
> you can provide a bit of further explanation.

Well, sometimes at least. I have to admit this far into this review my
head is beginning to swim a bit, so much information and threads of
discussion.

> If we take a typical example - your AFIO function from earlier - it
> issues at least three syscalls, every one of which has different latency
> when it succeeds or when it fails, and in addition, later ones are
> skipped when an earlier one fails, and to top all that off, the last
> syscall is an fsync, which does not inhabit the same galaxy as the words
> predictable latency.
> 
> So what use case are we targeting here where success and failure are
> equally costly and measured in cycles?

In most of AFIO 20 CPU cycles is utterly irrelevant. Indeed, 2 million
CPU cycles would be irrelevant.

But Outcome was always written for a SG14 low latency type audience. The
group is a bit misnamed, they actually much prefer predictable latency
over low latency. Some over there even compile release code with -O0 to
ensure they get exactly the performance of the source code written, no
surprises. That sort of thing.

As I mentioned before, if identical performance for success vs failure
is not what you want, and you really care about 20 CPU cycles,
expected<T, E> will always bias towards either T or E. It currently
biases to E, I've logged at
https://github.com/ned14/boost.outcome/issues/49 to rebias it to T.

Niall

-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/