On 10/23/17 08:21, Kagamin wrote:
On Friday, 20 October 2017 at 09:49:34 UTC, Adam Wilson wrote:
Others are less obvious, for example, async/await is syntax sugar for
a collection of Task-based idioms in C#.
Now I think it's doesn't fit D. async/await wasn't made for performance,
but for conservation of thread resources, async calls are rather
expensive, which doesn't fit in D if we prefer raw performance. Also I
found another shortcoming: it doesn't interoperate well with cache:
cache flip flops between synchronous and asynchronous operation: when
you hit cache it's synchronous, when you miss it it performs IO.
Actually I think it fits perfectly with D, not for reason of
performance, but for reason of flexibility. D is a polyglot language,
with by far the most number of methodologies supported in a single
language that I've ever encountered.
Additionally, MSFT/C# fully recognizes that the benefits of Async/Await
have never been and never were intended to be for performance.
Async/Await trades raw performance for an ability to handle a truly
massive number of simultaneous tasks. And it is easy to implement both
blocking and non-blocking calls side-by-side (MSFT appends 'Async' to
the blocking call name).
Here is the thing. Many projects (particularly web-scale) are not all
that sensitive to latency. Adding 10ms to the total call duration isn't
going to effect the user experience much when you've got 500ms of IO
calls to make. But blocking calls will lock up a thread for those 500ms.
That can disastrous when you have thousands of calls coming in every
second to each machine.
On the flip side, if you're a financial service corp with millions to
throw at hardware and an extreme latency sensitivity, you'll go for the
blocking calls, because they absolutely do cost less in overall
milliseconds. And you'll make up for the thread blockages by throwing an
obscene amount of hardware at the problem. Because hey, you're a
multi-billion dollar corp, you'll make back the few million you spent on
over-provisioning hardware in a day or two.
The point is that not everyone wants, or needs, maximum raw performance
per individual task. In the spirit of flexibility, D needs to provide
the other choice, because it's not our job to tell our users how to run
their business.
--
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
