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

2017-05-27 14:54 GMT+02:00 Niall Douglas via Boost :

...

...

...

...

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