I don’t do reviews and I don’t accept advertising. I just tell it like I see it and I try hard to be as brutally honest as possible when I do tell it. So if you contact me and ask me to take a look at your technology, know in advance that I never pull my punches. I will tear your pretty little baby into pieces if it so much as smells a little bit funny. Those of you who are familiar with my views on the multicore crisis already know that I am hard to please. I have strong ideas about how a multicore processor should behave and I will not compromise. And let me tell you, there is a lot of misbehaving going on out there. Right now, the multicore landscape is ugly as sin. Some people need an ass whipping, I swear. I especially dislike the crap being put out by industry leaders like Intel, AMD and the others. Lately I was beginning to despair of catching a glimpse of even a tiny hint of beauty in this dreadful landscape any time soon. That’s when someone brought Plurality Ltd to my attention.
Plurality’s Hypercore Processor
One cannot help being mesmerized by the unusual beauty of the colorful animation on Plurality’s welcome page. One is immediately struck with an irresistible urge to find out more about their technology. But Plurality, a small privately owned Israeli company founded in 2004 and headquartered in Netanya, is beautiful in more ways than one. In my opinion, their product, the Hypercore Processor, is a mixture of hyper beauty and a touch of ugliness. I’ll get to the ugly part in a minute. What caught my attention is that the company seems to have solved several crucial problems in multicore design that a behemoth like Intel, with all the gazillions that it lavishes on multicore research labs around the world, probably never even recognized as being crucial. Plurality’s engineers figured out a way to design a general purpose, fine-grained, self-balancing, auto-scalable, MIMD, 256-core processor! How cool is that?
The claims made by Plurality regarding the Hypercore’s so-called synchronizer/scheduler sound almost too good to be true. Take a look at the block diagram of their multicore architecture:
They’re claiming that their scheduler is able to perform near perfect load balancing. They’re also claiming that the cores can access shared memory without creating a bottleneck. This means that they are able to deliver fine-grain parallelism in a general purpose MIMD environment! This is incredible stuff. About a year ago I came up with a scheme to do fine-grain, real-time load balancing in a multicore computer. But then I realized that using a central controller to feed instructions one by one into a bunch of cores would not scale up as the number of cores increases. Here's a block diagram of my original design of the COSA multicore processor for comparison:
I also worried that having multiple memory caches would introduce unacceptable latencies if the cores had to frequently access memory in distant caches. In other words, my scheme was not scalable. I eventually thought of a decentralized mechanism (unpublished) that distributes the load-balancing task among the cores while keeping inter-core communication to a minimum. Apparently, Plurality seems to have solved, not only the scheduling problem, but the memory access bottleneck as well. How? I don’t know. It sounds almost like magic. If true, it means that at least one person at Plurality must be fully awake with a humongous thinking cap on.
I am not hiding the fact that I am impressed with Plurality’s technology. Them Israeli boys are kicking major ass and taking names on Core Street, there is no doubt about it. They seem to have delivered some of the really nice things that I’ve been craving for, for a long time now. Intel and AMD should be ashamed of themselves. Does this mean that I believe that Plurality has solved the multicore problem? The answer is no. Nobody’s perfect and, as they say, Rome was not built in one day. Still, when I have a bone to pick I must pick it. I don’t like Plurality’s programming model. I think their Task Oriented Programming model is crap. In this respect, they’re making the same mistake that everybody else is making. I understand the motivation behind retaining some similarity and compatibility with the legacy technology. This situation may look somewhat analogous to the time when, more than a century ago, the first horseless carriages had wheels and stepping boards that looked like those of the buggies that they replaced. It’s not the same thing. Plurality's multicore processor may look and sound like a Ferrari or a Lamborghini but it is still attached to a mule because there is no fuel in the tank. Here is their pitch:
Programming the Hypercore, beyond what is required when programming a standard unicore processor, is based on Plurality's unique Task Oriented Programming. The only programmer requirement is to perform a simple partitioning of the algorithm into specific tasks, and compose a task map accordingly.This is pure BS, of course. There is nothing simple about partitioning a sequential algorithm into parallel tasks and Plurality’s task oriented programming model is no different than breaking a program into threads. Plurality has simply given multithreading a new name in the hope that nobody would notice. Worse, the programmer has to compose a task dependency map on top of it! Come on, guys. You know better than that. I know you worked your butts off to get to where you are but your work is not done yet. Your programming model stinks. Your work will not be done until you come up with a processor that is designed from the ground up to support a truly parallel, synchronous reactive programming model like the COSA software model. Besides, what’s with the linguistic nonsense? Why would you want people to continue to program code like they did in the sequential days? This does not make sense. You either have a parallel processor or you don't. No way you’re going to tell me that you want to jump on board a shiny new 21st century spaceship and bring a pile of putrid 20th century garbage with you. Believe me, you will not be allowed into port until you jettison all that crap overboard. Take a look at Jeff Han's multitouch screen technology. That's the future interface of parallel programming. Just drag them and drop them.
Even though Plurality claims that “the Hypercore programmer needs not be familiar with the details of the machine, nor how its resources are interconnected and managed” (which is a very desirable and cool thing to have) I still think their programming model is crap. Having said that, I think Plurality is light years ahead of everybody else. I am not Jewish but I can tell you guys that, if you play your cards right, all the gentiles will come flocking like migratory birds to worship at your feet. You guys are riding the crest of a revolutionary wave. You have demonstrated that you've got what it takes to design and build a kick-ass multicore processor. You aren't there yet but you are onto something big, something that can potentially catapult your nation, Israel, into an economic and technological powerhouse, the Lion of Judah and all that. And we all know what that means. The correct multicore architecture is the legendary pot of gold at the end of the rainbow. The Israeli government should declare Plurality a national treasure and immediately pump 100 million dollars into its coffers. Ok, it’s kind of a joke, but I’m only half kidding. I’ll have more to say about Plurality in the weeks to come.
PS. Please get rid of that Plurality name. Look, this is a world market. Do you realize that the Japanese will have a hard time pronouncing your name? It sucks. You need something catchy like a cool Biblical Hebrew word or something. And why call your processor the Hypercore? That’s geeky and lame, in my opinion. Call it something like Abraham or Sarah, or Rebbecah or Joshua or Moshe or Elijah or Samson. Or something! Don’t be shy. Everybody already knows you guys are Israeli. So what? One more thing, why limit yourself to the embedded market? Go for the whole pie. That’s what I would do. Shalom.
Transforming the TILE64 into a Kick-Ass Parallel Machine
Tilera's TILE64: The Good, the Bad and the Possible
How to Solve the Parallel Programming Crisis