3 ms·
I don't see what this has to do with asynchronous or synchronous programming. If you have more work to do than what the core can handle, you're going to wait a
by icebraining 8y ago
I don't see what this has to do with asynchronous or synchronous programming. If you have more work to do than what the core can handle, you're going to wait a while no matter what style of programming you use.
- amelius 8y agoThe point is that the async style of programming will introduce unpredictable and potentially wildly varying service times. Contrast this to multithreaded programming, where the program is cut into thin time-slices which all have a similar, predictable duration.
- icebraining 8y agoAverage and variance are different things, though.
- kqr 8y agoI'm not sure I follow... If I understand the async style correctly, the idea is that a task will yield the CPU as soon as it is about to wait for I/O an insignificant time. This allows CPU bound tasks to race to idle, and prevents context switches unless they are nearly certain to be needed. I guess I understand your concern in the case of multiples tasks that are very CPU heavy, but that hardly seems like a universal issue. I also think it's a bit of a mathematical sleight of hand to use measures very sensitive to outliers with a distribution that generates large outliers in order to make a point. Perhaps the median or the 95th percentile is more useful. But less dramatic.