![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Entry tags:
The many-core future
If you're not already following it, I commend today's post in Ars Technica about the upcoming changes to hardware. It's not precisely new, but it does underline what I've been saying for the past couple of years: the time of Massively Multicore is upon us.
Everybody's getting used to having two or maybe even eight cores in a computer, and you can almost kind of ignore that in most cases -- after all, you're just writing one process among several on the machine, so if you're limited to one core it's not a big deal. You might even tweak the program to use a few threads. But Intel is now talking seriously about architectures that range from dozens to *thousands* of little cores working together. You can't ignore that if you're going to be doing any kind of serious programming.
There's a message here, and it's an important one if you're in the field: if you're not already good at multi-threaded programming, you need to *get* good at it. There are probably deep changes to programming coming soon -- they're hard to predict at this point, but the root message is that you're going to need to understand threading pretty well. Or you're going to need to learn the languages that are inherently threadsafe, like Erlang. Or both. If not, you risk confining yourself to the limited subset of the field where threading can be ignored. (Eg, the simpler forms of web-server programming, but not the really interesting bits.)
It's exciting stuff -- we may be looking at the most dramatic changes to the *art* of programming (rather than just its uses) in decades. But if you are seriously in this field, you need to be paying attention to it, and making sure your skills are up-to-date, or you risk dead-ending your career...
Everybody's getting used to having two or maybe even eight cores in a computer, and you can almost kind of ignore that in most cases -- after all, you're just writing one process among several on the machine, so if you're limited to one core it's not a big deal. You might even tweak the program to use a few threads. But Intel is now talking seriously about architectures that range from dozens to *thousands* of little cores working together. You can't ignore that if you're going to be doing any kind of serious programming.
There's a message here, and it's an important one if you're in the field: if you're not already good at multi-threaded programming, you need to *get* good at it. There are probably deep changes to programming coming soon -- they're hard to predict at this point, but the root message is that you're going to need to understand threading pretty well. Or you're going to need to learn the languages that are inherently threadsafe, like Erlang. Or both. If not, you risk confining yourself to the limited subset of the field where threading can be ignored. (Eg, the simpler forms of web-server programming, but not the really interesting bits.)
It's exciting stuff -- we may be looking at the most dramatic changes to the *art* of programming (rather than just its uses) in decades. But if you are seriously in this field, you need to be paying attention to it, and making sure your skills are up-to-date, or you risk dead-ending your career...
That was my first thought....
Or time to have compilers that do this automatically...I'm still not clear on why multithreading is left in the hands of the programmer when it's *so* easy to get wrong in horrible, unfindable ways. It's like garbage collection -- one of the places where the abstraction bleed is still inescapable, because state of the art is still crummy for handling this basic element of application infrastructure.
(True, GC is much better than it was 15-20 years ago; but it still can occupy a huge amount of processing space, in some languages (cough Java cough) seems to work at about 50% efficiency, and can routinely produce programs with memory leaks...)
Google's demonstrated that the MapReduce paradigm is a good example of a shift that leads to inherently parallelizable programs. I think it should be taught in Programming 201, just after recursion...
Re: That was my first thought....
Well, largely because it's difficult/impossible to do automatically in traditional languages, and people are used to traditional languages. To make it automatic, you have to change how people *think* about programs, and that's not easy.
Google's demonstrated that the MapReduce paradigm is a good example of a shift that leads to inherently parallelizable programs.
Oh, absolutely, and it wouldn't surprise me if that proves to be one of the primary shifts -- that that will push down from "architecture" to "libraries" to "language" pretty steadily. But that simply underscores my point that a programmer can't afford to be complacent in how he programs nowadays, because tomorrow it ain't gonna be the same.
(Which reminds me that I really need to get more comfortable with MapReduce myself: I've never worked with that particular architecture, and I owe it to myself to grok it deeply enough to know when to use it...)
Re: That was my first thought....
This is kind of why I brought up the GC example. When I was first taught programming, "automatic" garbage collection was some sort of weird voodoo that no one quite believed in, and you had to be very careful to make sure you free()d things, and such.
Wind forward some years, and Java's GC (while slow and inefficient) is essentially foolproof, barring a few memory leaks over the years (like Strings). And I'm hoping there's another 15 years of progress since then that have improved this situation.
Parallelically, I'm hoping that there's something we're all missing about multithreading along the same lines -- that some minor change in programming, possibly involving an extra layer of abstraction (by analogy with the functional -> OOP shift), will mean that we get multithreading for free. And no one will have to write locks or monitors or whatever, ever again, because they're just too easy to get horribly wrong.
And a pony!
Re: That was my first thought....
Honestly, my suspicion is not. Consider: people have been working on the parallelism problem a lot longer than the GC one. When I mentioned the current push towards multi-core architectures to my father a few months back, and the challenges it posed for programmers, he pointed out that sure, he was working on projects for that -- back in the 1960s. Everyone's known for many years that this day was coming: they've just pushed it off for longer than anyone originally thought possible through clever hardware wizardry.
My suspicion is that it *will* become automatic in the not terribly distant future -- but doing so will require a somewhat more major change to programming than that. Specifically, every promising-looking approach I've seen requires you to think about problems a little differently: tackling problems by decomposition, rather than as a sequence of instructions. The nature of those decompositions varies -- sometimes using an ecology of inter-communicating objects (as in Erlang), sometimes using a descriptive approach to programming (as in Haskell). But it's always about breaking the problem down into little pieces, and letting the recomposition happen automatically.
I don't know that that's really any harder in an absolute sense. But I'd bet it will leave some programmers who can't make the leap behind, the same way OOP did...