Re:Cinder: Instagram's performance-oriented fork of CPython
by pcwalton on Wednesday May 05, 2021 @03:46AM
(#27047241)
> Step 2: Build complex logic to untangle your nonsensical use of async/await and force things to run synchronously in the backend without the user knowing. See? A 5% CPU optimization right there!
Addressing your snark, I assume this optimization is targeted at places where you have a single "await" expression in the source that might call different functions at runtime, only some of which need to await.
Re:Cinder: Instagram's performance-oriented fork of CPython
by _carljm on Wednesday May 05, 2021 @08:30AM
(#27049042)
Or there are just different code paths in the called function (eg a “cache hit” code path and a “cache miss” one), and only some of the code paths need to await.
Re:Cinder: Instagram's performance-oriented fork of CPython
by toxik on Wednesday May 05, 2021 @02:50AM
(#27046930)
Asynchronous execution is not a replacement for parallel execution. That is not the value proposition of asynchronous execution models.
Re:Cinder: Instagram's performance-oriented fork of CPython
by nly on Wednesday May 05, 2021 @04:35AM
(#27047551)
This exact optimization has been implemented in C++ coroutines via the 'initial_suspend' coroutine traits hook.
...and those are stackless coroutines under AOT compiled conditions, so it only saves a malloc.
Step 1: "Who needs Threads? Just async/await all the things!"
Step 2: Build complex logic to untangle your nonsensical use of async/await and force things to run synchronously in the backend without the user knowing. See? A 5% CPU optimization right there!