On many-core, wasted cores, threads, processes, transactional memory, and the E-word.
Are Eight Cores Six Too Many? · Sun’s latest silicon, the T2, has eight cores, and a memory/thread architecture that, benchmarks suggest, can keep ’em all pumping. Well, so what? Jeff Atwood, in Choosing Dual or Quad Core, shows that for a whole lot of apps, anything more than two cores seems a waste.
It’s actually not a short-term crisis. There are plenty of Web workloads that naturally run wide rather than hot, whether you’re talking Java EE wrangling a thread pool or Apache in front of a bunch of LAMPware, PHP or Rails or whatever; plenty of work to soak up about as many T2’s as we can build, I’d bet. We haven’t had any trouble selling the less-muscular T1.
But I, and a lot of other people, would like to make more code run better on the new, wider, CPUs. As Jeff points out, “Unfortunately, CPU parallelism is inevitable. Clock speed can’t increase forever; the physics don’t work. Mindlessly ramping clock speed to 10 GHz isn’t an option.”
Transactional Magic Bullet? · In related news, it’s now public that the next wave of SPARCs will have hardware transactional memory.
So, is transactional memory, as in Rock, a magic bullet? [Heh; as I write this, the Wikipedia article on Transactional memory redirects to Software transactional memory. Not for long.] Everyone knows that heavily-threaded apps are often lock-bottlenecked, and transactional memory is a good way to do a whole lot less locking. Well, for the vast majority of programmers, Rock’s TM will be invisible; it operates in a very specific and kinda spooky way down at the instruction-set level. You’re just not gonna be wiring it into your cool new Web 2.0 app. Directly at least.
Where this kind of thing will be useful is down in the guts of core software infrastructure, stuff that gets as close to the metal as it wants. For example, the Java VM.
But Java is still thread-centric, and for really getting the most out of systems that are increasingly going to be many clustered boxes each with many fast-switching threads, you need to abstract away from that; to quote Sam Ruby, you need a Virtual Machine that is “designed from the ground up assuming that objects typically are immutable and serializable”.
The E-Word · Erlang disruption. Erlang influence. Erlang (and Erlang and Erlang) database substrate. Erlang for C#. Erlang thoughts. Erlang for Web 2.0. A first Erlang program. Erlang influence. Erlang distributed DBMS. Erlang message passing. Erlang (and Erlang and Erlang) for Jabber and Atom and IPC.
I smell a lot of interest but no consensus. I personally don’t think we’ll all be writing Erlang next year; pardon me for being old-fashioned, but I think that the human mind naturally thinks of solving problems along the lines “First you do this, then you do that” and thinks that Variables are naturally, you know, variable, and has grown comfortable with living in a world of classes and objects and methods.
My bet is that someone figures out how to apply Erlang thinking in a mainstream coding context and starts a landslide, because everything just starts running faster and reasonably cool, too. Then more cores are unambiguously better, if you can swing the memory bandwidth. And Transactional Memory? Seems like just the thing, at the core of such an infrastructure.
Contributions
Comment feed for ongoing:
From: Janne (Sep 04 2007, at 04:15)
The dual core/quad core post was interesting. Of course, I take away the precise opposite message from mr. Atwood - other than games, cpu-intensive applications _do_ benefit - and benefit substantially - from more cores.
In fact, I kind of question the inclusion of more than one or two example games for this kind of benchmark. Games really aren't cpu-intensive so much as they are graphics intensive. The solution for that is of course more and faster GPU cores, not cpu. Different problem, different solution. And to the extent that games do have cpu-intensive functionality, that functionality - from physics calculations to particle systems to AI - is really scientific functionality in thin diguise.
[link]
From: David Pollak (Sep 04 2007, at 06:34)
Well, there's Scala. It's a hybrid Functional/OO language that compiles down to Java bytecode and runs at "native" Java speeds on any old JVM.
The cool thing about Scala is that it's got a high performance implementation of Erlang Actors built in.
So, write your Erlang Actor style code, but run it on the JVM and call your favorite Java code.
I blog about how Twitter could be scaled with this technique at:
http://blog.circleshare.com/index.php?/archives/55-Prance-with-the-Horses,-Skittr-with-the-Mice.html
and you can read more about Scala Actors at:
http://www.google.com/url?sa=t&ct=res&cd=4&url=http%3A%2F%2Flampwww.epfl.ch%2F~odersky%2Fpapers%2Fjmlc06.pdf&ei=kV7dRpD7FqOOgwPf3LGGAw&usg=AFQjCNF9PMr-UskMyzt_eHi7Tzq2X01DbQ&sig2=sEwrkhQSPNaxnCbwwBFX1g
[link]
From: Taras Tielkes (Sep 04 2007, at 06:34)
So, does that mean that the "Rock Secret Contest" has ended? :)
[link]
From: Joe Van Dyk (Sep 04 2007, at 06:51)
Seems like more cores (with more memory) means you can run more virtual OS (solaris zones, Xen, whatever) on the same box.
[link]
From: Joe English (Sep 04 2007, at 07:26)
On variables that vary -- I'm not sure how natural this really is. Anyone who learned algebra before learning to program almost certainly faced a conceptual challenge on their first encounter with a statement like "x = x + 1".
[link]
From: Dan Sickles (Sep 04 2007, at 08:22)
Erlang.Erlang. On the JVM, you could use Scala. Scala. It's statcially typed, has actor-based asynch messaging (via a library), deep OO and is functinal too. Kitchen Sink? Perhaps. After few months of hands-on, it feels right to me.
[link]
From: Isaac Gouy (Sep 04 2007, at 09:37)
'the human mind naturally thinks of solving problems along the lines “First you do this, then you do that” and thinks that Variables are naturally, you know, variable...'
Maybe you're thinking of cause & effect arguments?
It seems that the natural world has a gazillion different things happening at the same time - maybe we're quite good at dealing with that.
Maybe you learned programming so long ago that you have simply forgotten that you learned variable assignment?
[link]
From: Scott Johnson (Sep 04 2007, at 11:17)
Another good Erlang link: Joe Armstrong's blog.
[link]
From: Wes Felter (Sep 04 2007, at 12:42)
What do Windows games have to do with the T2? Maybe instead of a multicore crisis we have a one-size-fits-all crisis, as in: if you assume that there can be only one processor design, that design will disadvantage some applications.
[link]
From: David Magda (Sep 04 2007, at 16:38)
Wes Felter makes an interesting point. Operating system monocultures are often talked about in a security context, but given how x86 dominates the marketplace in many spheres, are we selling ourselves short?
Sun, by using x86, 'regular' SPARC, and 'Niagra' SPARC has three different ways of doing things, and each may be good in different situations. IBM also has some different options available (as well as HP to some extent), but people tend to try to solve things in the Wintel-way because that seems to be the dominant way of thinking.
The consolidation of architectures has made many developers' lives easier since they have to compile for fewer variations, but has it in turn limited the options we have in solving problems?
[link]
From: Revence (Sep 04 2007, at 22:04)
Brilliant article, well-written. Nice read. But... :o)
Sure, we now expect variables [to be variable]. But we don't expect them variable in a non-deterministic way. Also, we can just dump the whole variable idea (it's starting to look like explicit variables are accidental complexity). We can just let the compiler create them, rather than the programmers.
[link]
From: Josh Anderson (Sep 04 2007, at 22:35)
Is eight cores six too many? Not when you're running a busy web server or database, or other application.
Did server applications even cross your mind? You are talking about a chip that will only ever be used in high-end servers and comparing it to desktop CPUs. That's apples to oranges, I'm afraid.
[link]
From: Dan (Sep 04 2007, at 23:25)
Erlang is such an easy language to program in. It's so much simpler than Java, Ruby, C#, etc. The absence of objects and mutable variables makes Erlang code much more readable, debuggable, and modular than code written in those languages. You have to use it to know what I mean.
[link]
From: Anon. (Sep 06 2007, at 08:47)
It is common knowledge that women are better at multi-tasking (and we are better at reading maps), so it may be that the male dominance of programming will come to an end with multicore friendly programming languages? :)
[link]