A very interesting slide deck comparing sync and async IO

[deadalnix via Digitalmars-d]

On Friday, 4 March 2016 at 22:22:48 UTC, Ola Fosheim Grøstad 
wrote:
> On Friday, 4 March 2016 at 03:14:01 UTC, Ali Çehreli wrote:.
>> And that's exactly one of the benefits of fibers: two workers 
>> ping pong back and forth, without much risk of losing their 
>> cached data.
>>
>> Is my assumption correct?
>
> Not if it is hyper-threaded, as pairs of threads are sharing 
> resources.

Irrelevant.

> Otherwise you are just benchmarking a suboptimal pattern. Which 
> makes sense when optimizing an existing application, but makes 
> less sense when designing a new database engine from scratch.

async do not make any sense on a DB. You want async when you are 
bound by a 3rd party system.

For instance, if you have a frontend server that is bound by DB 
access, async will allow to shift you frontend code from DB bound 
to CPU bound, allowing you to get much more bang for the buck in 
your frontends. Now, if you limiting factor is IO on your own 
machine, like say local disk access, then it's going to change 
nothing (in fact, it may make things much worse as disk prefer 
sequential accesses).