|
Boost Users : |
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2021-02-10 14:28:51
NOTE: This is becoming off topic for boost-users.
On 10/02/2021 13:10, Richard Hodges wrote:
> Chris included sender-receive into asio out of politeness as far as I
> can tell.
No, the committee took a vote and said they were to be supported. As a
proposal champion, you now have a choice between (a) abandon your
proposal (b) write a paper proposing an alternative implementation of
the committee's choice into a least worst formulation (c) adopt them as
understood when the vote was taken.
Chris chose (b) for Sender-Receiver, the committee accepted his
alternative formulation, we all moved on.
> The Committee certainly has not "bought into it". Discussions continue, with
> Ville (IIRC) recently (correctly) suggesting that it be hived off into
> its own paper.
Until the committee takes a vote changing direction, preceding votes are
all that matters. Suggestions by any individual, even one as esteemed as
Ville, are merely ideas until voted upon.
> What is actually happening is that a vociferous minority interest group isÂ
> pushing its own idea of what is fanciful, without regard for the wider userÂ
> base.
That's not how things work. There is, by definition, a small group of
domain experts in any particular topic on WG21. Of that group of domain
experts, I would say there is an overwhelming majority dissatisfied with
the current proposal. What the committee ends up adopting will always be
somewhere in the middle where a consensus could be reached, and
everybody fairly equally dislikes the proposal.
>From the outside, it looks like only a few dozen people ever do
anything, but internally one tends to trust the opinions of the domain
experts and follow their leads on a particular topic. Me personally, I
have been consistent in wanting ASIO standardised as-was but for it to
not monopolise the whole of the Networking, Concurrency, Execution and
Parallelism space i.e. it should "plug into" everything else, but
otherwise be left alone. So looking at the current proposals, I've got
much of what I'd prefer, but not all of it. I am extremely sure Chris is
in a very similar position, as is everybody on WG21. Consensus building
means those sort of outcome.
The biggest problem with consensus building is it leads to overwhelming
complexity in order to please enough people. The whole Executors and
Networking space as currently proposed is hideously more complex than it
could be, and that will only get worse as WG21 grows in number.
> Fancy words mean nothing Niall, what is at stake here is C++ being usefulÂ
> for networking in server applications out of the box. A perfectly
> acceptable,
> ubiquitous, production tested, solution was proposed by one brilliantÂ
> concerned individual.
You don't need to keep making things personal with me or others. I have
no axe to grind with you. I'm taking the time to inform you that what
you think is the situation may not be the situation. Of course it's all
opinions and interpretations, and if Ville or Chris were doing this
they'd have quite different opinions and interpretations to mine. But
I'd like to think that mine are not a wildly inaccurate interpretation.
Just different than some echo chambers that I suspect you spend a lot of
time within.
As I've often said, ASIO is great for what it was designed for. But it's
not great as you get away from that. At work we run our custom database
inside an isolated segment of AWS where S3 performance is highly
predictable and the network is entirely ours. We currently use ASIO
running over a thread pool. The AWS instance has a 25Gbps network
connection, we currently transfer a few dozen Mb per S3 request, so
that's about a 1000-5000 us latency which is easily lost in the ASIO
latency noise. However in the near future we shall be making 100x more
requests at 100x smaller S3 requests. Now the i/o latency becomes as low
as 10-50 us, and now replacing ASIO with something with stronger
guarantees starts to look profitable.
I'm not saying that we shall actually replace ASIO, it's all wider cost
benefit in the end. I am saying that ASIO's design is not as ideal as
others for bounded latency i/o of lots of small packets where something
like libunifex has a much more appropriate design for that particular
use case (and indeed, this is exactly what FB intends libunifex for).
> Then a hoard of untalented engineers mobbed
> the agenda to push something no-one else wants.
Original ASIO had a very incompatible conceptualisation of concurrency
and parallelism to where WG21, especially SG1, is currently at and
indeed where it intends to go. Reconciling the two conceptualisations
was never going to be easy, indeed a large part of original opposition
to ASIO becoming Networking was precisely ASIO's strong and fixed
opinions on how concurrency and parallelism ought be to framed.
The "hoard of untalented engineers" has a wealth of domain experience in
a far wider range of computing systems, ones that ASIO's original
concurrency model would not work well with e.g. ASIO's original model
would not work at all well on a GPU, or on a thousand CPU machine, or
non cache coherent systems, and so on. They are trying to generify that
model into something less fixed.
I may not agree with the outcomes, but I agree with the intent and
spirit and goodwill behind the effort. And I most definitely consider
the engineering talent involved to be world class. Some of the people
who have contributed to this know more about atomics than quite
literally anybody else on the planet, for example. And they're not the
exception in there, that's the level of talent common in WG21.
Just because they're not doing things the way you want in a timeframe
you want makes them untalented or pushing things no one else wants.
They're doing their jobs, representing their employer's interests, and
there is a convincing argument that those employer interests point
broadly in the direction travelled to date in this area by WG21.
Remember after all who pays for WG21 to operate, and thus by definition
it is their interests served first before all others.
Niall
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net