multi core ponderings

Eric Schrock’s post about dual-core Opterons and the changes that have to be made to Solaris to deal with the Opteron’s “near, far, farther” NUMA layout (vs. what’s already in Solaris 9 to support Sun’s SPARC-based NUMA machines) got me thinking about the upcoming multi-threaded / multi-core CPU trend.

Well, it also reminded me that our 4-way, 32GB Opteron box still freezes twice a week.. even with the latest 2.6.X kernel.. But that’s another story.

Back to multi-core CPUs. It’s clear to me that this is very likely an unescapable destiny. It seems we’ve finally hit the wall on cranking up the clock speeds ad infinitum. It’s also clear that the operating systems are well positioned to effectively deal with both Chip Multi-Threading and Chip Multi-Processing — Solaris, Linux, and even Windows Server all have sufficient NUMA support these days. I would argue, however, that there’s been little progress in the programming world to make multi-threaded programming any easier for the average programmer. The first step was hyperthreading, now dual-core, and in just a few short years we’ll be working with things like Niagara where a single chip can run 32 simultaneous threads. Can we take advantage of all these opportunities for parallel execution?

On the desktop I don’t think we’ll see any major adoption problems — mind you I don’t think we’ll see much benefit either — since we already have plenty of CPU to run our Windowing system, web browser, email, and word processor. The gamers will be happy since they probably *will* see some benefit from these advances. Today’s games are basically all running on a handful of 3D engines. The guys who write these game engines are brilliant coders who have already largely moved to multi-threaded designs to let people with SMP and HyperThreading systems get more FPS. Just how well an engine scales across multiple execution threads may become a significant factor in how successful the engine becomes. Carmack ought to do well.

What really has me wondering is how this trend will play out on the server. Why the server? Cause while you’d think a massively multi-threaded box would fit well with today’s “internet workload”, the server is where I’m seeing a massive increase in the use of the so-called “dynamic languages”. Python, Perl, and Ruby. None of which has an effective way of mapping VM/interpreter threads to native system threads. I’m also seeing a huge increase in the number of places and situations where web apps are being deployed instead of traditional win32/x11 apps. Unlike on the Internet where ASP, PHP, and Java rule supreme (for now), developers are flocking to simple, productive toolkits like Zope and Ruby on Rails to speed devlopment of these “embedded web apps”. Just because it’s a web app doesn’t mean it will be handling thousands of requests a minute from the Internet. Increased clock speed has opened up new realms of development techniques in this arena, but will the languages (and their virtual machines) be able to reap the benefits of a multi-core CPU?

My next post will look at the case for dynamic languages and how increased productivity is more important than program optimization. Will the growing popularity of dynamic languages have some bearing on the ultimate direction of the CPU industry or vice versa?