Re: [boost] [outcome] Andrzej's review

Subject: Re: [boost] [outcome] Andrzej's review
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2018-01-26 23:47:25

>> Why accepting this library when we have `expected` being standardized? I do
>> not really mind having two in Boost.
> 
> I agree, we should not be rejecting libraries just because another similar
> library already exists in Boost.

There is no similar library already in Boost. Expected will not be
submitted to Boost, it's in LWG now.

I believe Andrzej meant "second" or "alternative", not "two".

>> First, it is ready, being proposed,
>> and applied in a number of non-trivial code-bases. Niall claims that his
>> trade-offs are better tailored to predictable-latency applications. I do
>> not have enough knowledge to asses it. They look convincing. The only way
>> to test it is to give this library the Boost blessing and have the user
>> test it.
> 
> Here I disagree. If there are issues with a library, they should be
> addressed before it is accepted; we should be proposing/accepting only
> relatively mature libraries that have seen real, if limited, deployment.

At a minimum, Outcome v2 is already in production use at Microsoft and
at Google. I have received bugs reports :) I suspect a few other
multinationals are also using it in production, but I cannot be sure.

> First, this is a matter of quality standards. Secondly, fixing problems
> when there already is substantial user base is messy, and often requires
> further compromise.

I believe Andrzej was specifically referring to the fixed latency use
case only.

On that the only hard evidence I can provide is AFIO benchmarking on
Intel Optane technology. AFIO, which uses Outcome throughout, benchmarks
at a minimum of 100 nanosecond i/o latency on Linux (pre Meltdown
mitigations). This is statistically indistinguishable, to a 99%
confidence interval, to calling the kernel syscall directly.

How useful Outcome is for fixed latency programming below 100
nanoseconds per operation I cannot say with any statistical confidence.
Also, other workload patterns may differ significantly to kernel i/o.

In the end, people ought to give Outcome a try for their use case and
see how it goes for them. Which is what Andrzej was saying I believe.

Niall

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