Does async/await solve a real problem?
bjouhier at gmail.com
Thu Sep 11 14:27:51 PDT 2014
I forgot to mention performance.
streamline has been an interesting playground to test performance because
it supports 3 different backends:
- pure callbacks with a sophisticated CPS transform
- fibers (much simpler transform)
- generators (transform is similar to fibers, runtime is a bit trickier).
Pure callbacks are the fastest when the execution stacks are shallow and
the logic is simple.
When the call stacks get deep and/or the logic gets complex, fibers win.
This is because we have several layers of async functions calling async
functions before we hit low level callback APIs. The intermediate async
calls are executed as normal calls with normal returns (no callback, no
allocation of a generator object) until we reach the low level callback
APIs (where a Yield pops up). With some code patterns like caching (where
only the first call is truly async) the fibers backend can be order of
magnitudes faster than callbacks (even handcrafted ones).
Generators always lag behind (but they have more regular memory patterns
than fibers). Part of this poor performance may also be due to lack of
optimization in V8.
If async/await is baked into the language VM implementers will be able to
choose between different strategies: callbacks, single frame continuations,
deep continuations, ... to optimize the code. The nice thing is that the
await markers will always be there on the surface, even if the VM takes
some shortcuts below.
2014-09-11 22:48 GMT+02:00 C. Scott Ananian <ecmascript at cscott.net>:
> On Thu, Sep 11, 2014 at 4:41 PM, Bruno Jouhier <bjouhier at gmail.com> wrote:
> > I think that Mark Miller nails it really well:
> >> The cost of making atomicity cheap is that interleaving points must be
> >> made explicit. With callbacks, this cost is quite high. Promises reduce
> >> cost substantially. async/await further reduces this cost about as far
> as it
> >> can be reduced, while still leaving an explicit marker.
> > IMO promises are only a step forwards; async/await is a leap forwards.
> And, at the risk of banging my own drum -- async/await pave the way
> for some really interesting work with optimistic transactional locking
> and speculative execution, since they are (as noted in this thread)
> explicit markers of atomicity boundaries.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss