Re: [boost] This AFIO review (was: Re: [afio] AFIO review postponed till Monday)

Subject: Re: [boost] This AFIO review (was: Re: [afio] AFIO review postponed till Monday)
From: Rodrigo Madera (rodrigo.madera_at_[hidden])
Date: 2015-08-23 01:53:12

On Sat, Aug 22, 2015 at 9:38 PM, Niall Douglas <s_sourceforge_at_[hidden]>
wrote:

> On 22 Aug 2015 at 19:43, Glen Fernandes wrote:
> > Am I to understand that by design, AFIO's
> > implementation implies lower performance than an alternative? (even if
> > that alternative is something like libuv, which has its own flaws)
>
> Current performance benchmarks can be found throughout the
> documentation, specifically the tutorials, the release notes and the
> reference documentation.
>
> Is it lower performance than alternatives? Almost certainly, and the
> documentation takes pains to present AFIO in a worst possible light
> in any comparative benchmarks presented so nobody is under any
> illusions. What matters is correctness, reliability, reusability and
> portability - and most importantly of all - do NOT lose other
> people's data.
>

Sorry, but I have to disagree tremendously.

Performance is the only justification I can give clients (and bosses) of
having such complex code as asynchronous programming requires. Justifying
Boost.ASIO is an exercise in marketing, and the benchmarks are the killer
chart that sell complexity. If not by that, Qt would be the chosen path in
many non-academic projects.

I even see a use case for AFIO in one of my products, where extreme write
performance with minimum IO is a first priority, and a big effort was made
to implement a subsystem for fast writes under the specific environment.
Effort so big that the project froze until the writer code was done.

The point of this is that performance should not be low priority. Specially
for a boost library, and even more so for an asynchronous library. Citing
correctness is not a feature to me. It's just basic principle. You are
assumed to have it.

As soon as AFIO is really competitive for me to use, I wish to do a full
review. As for the general API usage I'm not sure that a full blown review
is needed for that. The library is not finished, and you said, and a review
now will be just like our past review, where a very interesting library is
just not ready yet. And in your case, it doesn't yet perform.

Reviewing of incomplete library work is not ideal, IMHO.

That being said, I have some questions:

Benchmarks,
Do you have usable coroutines examples now? The web sample uses futures.
Do you have better performance numbers when using them?
What good measures did you employ to prevent caches from contaminating
benchmarks?
Do you believe that performance will improve?
Do you know what your bottleneck is?
Why do other libraries do better? Can you imitate that while still leaving
your superior API?

About coroutines,
Do you really need C++1z?
Why not Boost.Coroutine emulation for backwards support?
Why do you use C++11 at all? C++03 is still widespread and a requirement
for most projects still.

Thank you for your time,
Rodrigo Madera