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

Subject: Re: [boost] [outcome] How to drop the formal empty state
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2017-05-27 17:17:31

2017-05-27 14:54 GMT+02:00 Niall Douglas via Boost <boost_at_[hidden]>:

> >> >> 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.

Interesting. Did I missed that in the docs? According to your description
it should be really relevant to people who make a decision whether to go
with your library or not.

Regards,
&rzej;