Based on Sutter’s findings – as we’ve moved to the modern world, paying attention to register/L1/L2 cache usage is significantly MORE important now than it ever has been. A theory I really believe in (again from Sutter) is that “old-school optimization will soon be very sexy again.”
So let’s consider a pathological case for memory latency. Imagine a system where to maximize flexibility memory allocation patterns are organized around many small allocations. This blows most data locality out of the water – as we walk from object to object, we’re typically walking from data page to data page – eliminating all of the nifty caching the processor is doing for us. In fact, the more memory allocations our program performs, the worse our latency penalties as memory chunks are further dispersed. Now imagine that system also needs to GC (reachability/mark-and-sweep/tri-color) to determine if memory is reclaimable – the processor cycles executed are minimal, but the memory penalty? Abysmal.
A major system with these penalties is Managed code (Either Microsoft or Sun/Oracle). Vista was originally going to have large components in managed code. The result?
http://www.microsoft-watch.com/content/developer/the_dirty_little_secret_about_longhorn.html
Managed Code Is Slow. And I don’t believe it’s ever going to get better. In isolated benchmarks it will be very competitive, the compilers and jitters are pretty good – but when you take it to full scale, memory use kills. Add junior developers who love XmlDocument and Hashtable and you’re further down the rabbit hole.
And how do people solve for slow managed code? They throw more hardware at it. Why have your code run on 1 machine when it can run in 100?
This guy is a troll: http://blog.expensify.com/2011/03/25/ceo-friday-why-we-dont-hire-net-programmers/ – but he’s right about one thing. We need to really understand what our systems are doing in order to efficiently available resources.
Leave a Reply