Re: [Async] Naming land grab?

From: Klemens Morgenstern (klemensdavidmorgenstern_at_[hidden])
Date: 2023-10-09 01:50:12

> I challenge the author with this exhortation: get a user or two, show that
> this thing is compelling enough to be used outside of the Boost community
> in an actual project, and then submit it. What is so hard about that?
> What's the rush to put this into the collection? If it's good it will be
> just as good two or three releases from now. And no one will be impeded
> from using it even before it becomes part of a release.

... what makes you think I have zero users? Who are the people opening issues?

> Klemens: why do you have zero users? The question is of course rhetorical
> because we already have the answers. No effort was made to acquire them, no
> thoughtfulness was put into actual user needs, no users were consulted
> during the development of the library. How many times was Peter Dimov
> consulted during the library's development? Did Christopher Kohloff offer
> his input?

I have users. I have talked to them and to potential users to refine
the API & scope.
You keep assuming the worst here and you're wrong on almost every point

I did reach out to Peter & Chris as well, but neither led to any input.

Now you're just making up things.

>
> In the first review cycle for the library it was said that the library is
> single threaded and it made sense to optimize:
>
> https://lists.boost.org/Archives/boost/2023/08/254938.php
>
> I got no answer to this question so I asked it again:
>
> https://lists.boost.org/Archives/boost//2023/08/254958.php
>
> Still no answers to this question from August, the author provided no
> information about how the library is optimized, what kind of improvement
> was seen, the methodology for optimization, any kind of benchmarks, and so
> on. There is just a handwavey claim of performance. Is this how low Boost
> has fallen now? What happened to the engineering rigor and discipline that
> was the hallmark of Boost's heyday? Must we resign ourselves to the
> indignity of statements like "I don't see anything wrong with an author
> seeking acceptance in Boost as a way to acquire users?"

It didn't sound like a serious question - my docs have a benchmark
section, you know?

async uses symmetric transfer all over the place, which is the main
optimization over asio.

Using pmr is not really an optimization, but a customization point one
can disable at compile time.
I didn't want an allocator template parameter everywhere, so pmr is
the standard version of achieving this.

Beside symmetric transfer, async uses a small buffer in the coroutine
frame which gets used for the associated allocator of an `co_await
async_foo(..., use_op)` expression.
Depending on the memory required by the op, that can mean that no
allocations take place at all. The upstream of the sbo depends on
whether or not PMR is disabled.

See the "Operation Allocation": https://klemens.dev/async/benchmarks.html

>
> Sad.

This thread is making me sad indeed.