There's been a bit of talk on the web-o-sphere about a report out of the German tech magazine Hiese.de that claimed that the Larrabee multi-core processor that Intel was working on will contain 32 original (well, second generation, but still 20 years old) Pentium cores. In the end, it appears to be just speculation and Intel was quick to squash the rumors. But the logic behind the speculation seems plausible.
The old Pentiums where 3 million transistors and with the new GPUs coming out with over a billion, you pack a lot of cores onto one of those. And I like the concept. Something old is new again. Simplify and multiply. There are a lot of transistors in modern CPUs just to handle out of order execution and try to do as many things at once at the instruction level. But that's pretty complicated but made it simple for the programmer. We've gotten pretty good at doing the simple things, why not just take a step back and use what we know. But, of course, you still need to software to take advantage of it.
Reading the discussions really opened my eyes a bit more. This 32-core thing really is possible and will happen within the next year or so. Are we ready to build software applications that can do 32 things at once in an organized fashion. Thinking about it a bit over my holidays here, there is some existing technology we can use and it'll be pretty familiar. I'll blog more about it in a couple of days or so, but think C++, generics, SystemC, UML action semantics. Mix them all in a pot and I think we can come up with some "soup for the multicore programmer's soul"...
I have to respectfully disagree. C++ is not part of the solution of the multicore problem. C/C++ gives you good sequential performance, but that will not matter too much when we have cores in abundance. You'll have to elaborate on the part about UML action semantics, though... ;-)
ReplyDeleteThe future belongs to languages and tools explicitly designed for a concurrent world, such as Erlang and Mozart.
@jespere
ReplyDeleteWhile I think frameworks and languages will help with the concurrency problems we will face, I am extremely hesitant to accept any as a magical cure. That isn't to put down your point, jespere, but merely to put it in perspective and perhaps add a word of warning :)
All too often something gets sold as a solution to all our problems, only to bring additional technicalities that are not well understood. In my own limited experience, I have found this to be the case with garbage collection, Java, C#, various .NET technologies, COM, Visual Studio, and yes, even Eclipse. That is not to say they don't have their place. Recently I have been working with Map/Reduce (using Hadoop) for highly concurrent processing. It is pretty effective (and fun :), but even there, if you don't understand the assumptions made by the layer(s) below you it is so easy to get into trouble.
IMHO, nothing can replace developer understanding and discipline. In any large scale project, I imagine the solution will be a mix of different technologies, each chosen for a list of pros that outweigh the cons.
Great points snapp. Even looking at Web 2.0, it's clearly a combination of technologies that make for an interesting architecture.
ReplyDeleteThe same should be true for multicore. Not every problem we solve with software needs or even works with parallel processing.
But I am very worried that the average programmer will be overwhelmed with the complexities of multi-threaded programming and I'm just looking for something that can help.
As for whether C++ is part of the solution, I'd have to say I never thought it could be used for hardware circuit emulation which is inherently massively parallel, but it is (SystemC).