Let's talk actual examples. I've read the article. Can you give me a concrete example of the "attack of the killer microseconds"? Something that doesn't boil

Let's talk actual examples. I've read the article. Can you give me a concrete example of the "attack of the killer microseconds"? Something that doesn't boil down to "the article said so" or "we analyzed Google's data center and we found we're running poorly written software on it?". Something that is fundamental. I've worked on software where the amount of context switching was so high that it consumed a significant amount of cycles (on hypervisors this used to be a bigger problem btw, and maybe still is) and we analyzed the problem and fixed it reducing the number of context switches by a factor of 10. The bottom line there was poorly designed software. I understand the author wants to have his cake and eat it or in his words "code simplicity and programmer productivity". He wants some magical architectures where software engineers don't have to worry about tradeoffs, the OS or the hardware. They should be able to write 500 lines Python and the whole thing will run in a single cycle and do I/O and compute at the same time. They should be able to write 1000's of threads with a working set of gigabytes and not worry about the size of the L1 cache. They should be able to write a 10GB file 1 byte at a time. That's unlikely to happen. In the meantime specific engineering problems can be solved with specific techniques. The author's conclusion: System designers can no longer ignore efficient support for microsecond-scale I/O, as the most useful new warehouse-scale computing technologies start running at that time scale. Today's hardware and system software make an inadequate platform, particularly given support for synchronous programming models is deemed critical for software productivity. Micro-second scale I/O isn't new. Low level I/O devices always operated at these time scales. Writes to disks with memory buffers. Sequential disk reads. Networking. Video cards. From a software perspective very low overhead concurrency goes back to coroutines in the 1950's through various forms of lightweight threads. The ASICs inside your typical rack-top switch are running software that is absolutely capable of handling this sort of workload efficiently. I think what is a relatively new phenomena is that there are a lot of developers who don't understand anything about the underlying hardware. The other thing that has happened is that systems have become more complex. It's not easy for someone to go from "wasted cycles" in the data center to the design issues that are the cause of these inefficiencies. People have tried many different permutations of software and hardware architecture and I think it's unlikely that they completely missed the magical one that lets you have your cake and eat it. The primary reason being that the constraints are physical ones. Can we do things a little more cleverly? Sure, we do that all the time. I keep coming back to real-time OSes not because this is necessarily a hard real-time situation but because real-time OSes have forever had very lightweight threading, the ability to handle interrupts in lower layers of the stack, zero copy network stacks etc. They are an off-the-shelf solution for some of the problems discussed. Obviously (or not so obviously) there is a price to pay for giving up a lot of the "luxuries" of high level OSes but mere-mortals are absolutely capable of working in this environment. If it's not clear ;) I didn't like this article. EDIT: Another IMO interesting observation is that a lot of the techniques for dealing with storage I/O are from times where CPUs were a lot slower. For the longest time ~10ms seek times were relatively constant as CPUs got faster by orders of magnitude. So in some sense a microsecond latency SSD on a 3GHz CPU is already benefiting from a lot of work that went into shaving cycles from the millisecond I/O on the 8Mhz CPU of past.