A very interesting slide deck comparing sync and async IO

deadalnix via Digitalmars-d digitalmars-d at puremagic.com
Thu Mar 3 18:01:33 PST 2016


On Thursday, 3 March 2016 at 17:31:59 UTC, Andrei Alexandrescu 
wrote:
> https://www.mailinator.com/tymaPaulMultithreaded.pdf
>
> Andrei

A lot of data presented are kind of skewed. For instance, the 
synchronization costs across cores are done at 0% writes. It 
comes to no surprise that synchronizing read only data is cheap, 
but I don't think the author is justified in concluding that 
synchronization is cheap in the general case.

"new threads are created if all existing are busy but only up to 
MAX_INT threads" More likely only up to the point you run out of 
file handles.

You got to also note that context switches are measure on an 
opteron that has a 81 cycles iret (it is 330 on haswell) so that 
would explain why he find out they are way cheaper than expected. 
Opteron also have 2x64kb L1 cache, which probably reduce the 
cache trashing due to context switches at the cost of single 
threaded performances (which doesn't seems like a very good 
tradeoff for a CPU). In short, the CPU used is good for context 
switches, especially compared to modern intels.

Other result are not that surprising, like blocking IO being 
faster than non blocking one, the gain from async coming from 
multiplexing IO, not making every individual IO operation faster. 
Or, in server terms, it'll change your DB bound frontend to a CPU 
bound one and offload scaling on the DB. If you don't have 
another component to limiting your server, going async is not 
going to improves things (like if you are already CPU bound).


More information about the Digitalmars-d mailing list