Code Parallel or Die, Part 2

Frank Chism — Tue, 15 Apr 2008 19:40:00 GMT

It’s multicore time. Do you know where your parallelism is?
Do you know where your parallelism is? Well you better find it! This is because you must or your users will not see the doubling of performance that they have seen for the last seven or eight generations of microprocessors. Why? Well the chip makers ran out of physics, clocks just couldn’t go a lot faster every few months the way they used to and more cores, even if they double or triple the performance of the processor do not lead to a faster feeling system if all the applications are serial. So, is your application serial? It better not be.

Two examples from my own life demonstrate the user and buyer frustration we are about to hit head on. First my sister, a long time Mac user, bought a new dual socket dual core Mac. On paper this system was easily three to five times “more powerful” then her previous system, a dual processor Mac. Her first complaint was, “It doesn’t feel faster. It certainly doesn’t feel ‘wicked fast’ compared to my five year old system.” I pointed out to her that what she had was more power, not more ‘faster’. I told her to try doing more than one thing at once. It took awhile for her to get the hang of this, but one day recently she called and started raving about how ‘powerful’ her new system was compared to her old one. What she had learned how to do was to get three or four long running tasks to run in the background while continuing to do her interactive day to day tasks without any noticeable degradation in interactive performance!

As a second example, for Christmas I built my wife a new dual core system because she was complaining about her system being too slow and crashing all the time. It was a thing of beauty with twice the CPU, twice the memory, and five times the capacity and twice the bandwidth of her old disks. The processor was two generations newer with a 20% faster clock and over four times the memory bandwidth. I was ready for a big hug and profuse thanks for my intelligence and craftsmanship. Boy was I in for a disappointment. What I got was, “It isn’t any faster.” I am a victim of the core war!

The lights are on, but there’s no parallel home.
Well my personal tragedy was nothing compared to what will happen to any software developer or corporation that depends on their fortune or fame to flow from people using their product and liking the experience. That is, it will be tragic for those who do not start to think parallel for every step of every phase of every program that they write and design in parallel not try to graft it in afterwards. Just as with security, and network awareness, you don’t get good results trying to add in parallel later. You must start in parallel and continue in parallel and only go serial as a last drastic measure and then only for the shortest possible time. Sadly, even in my own backyard of High Performance Computing the number of programs that have tried to graft in parallel rather than design it in is appalling. What they end up with is often what I call the ‘Silence of the Lames’. That is, a lame parallel port that doesn’t scale or doesn’t speed up their program nearly as much as is possible.

Now you might say that this only works for scientific programs with massive amounts of data. Well, sorry Charlie, if your product is something as ‘serial’ as a document processing program like Microsoft Word, you had better be thinking how you can use those extra cores to improve the user experience. Why? Well as I said in the beginning: Code parallel or die!

For the want of a nail, the shoe was lost; for the want of a shoe the horse was lost; and for the want of a horse the rider was lost, being overtaken and slain by the enemy, all for the want of care about a horseshoe nail. - Benjamin Franklin

That’s all for now. I enjoyed writing this and hope to hear from some of you about what you think of my ‘Parallel Imperative’ and what you can personally do about it.
So, never stop studying and I’ll blog at you later.

- Frank

Code Parallel or Die

Frank Chism — Mon, 14 Apr 2008 17:22:00 GMT

“What we have here is a failure to communicate.”
- Luke in “Cool Hand Luke”

A fist full of cores in a server rich environment.
If you haven’t noticed that the world has changed, you had better wake up and smell the coffee. The era of killer apps written in serial code is ending. Like the norm in species extinction, the reason many ISVs will not survive this change is that the environment in which we develop code has changed rapidly and not all species can adapt to this new world. The change was preceded by a hint of ‘The Shape of Things to Come’ in the Beowulf and compute cluster revolution. This revolution created the first generation of commodity clusters based on microprocessor nodes connected by commodity networks. An evolutionary message from this generation is that if you are building a cluster you really ought to use server class nodes. You _can_ build a cluster from desktop parts, but the higher you scale your node count the more you want the convenience and reliability of server parts. I remember seeing a look of outrage on the face of an Intel marketing person when I commented that I thought their then brand new Itanium Tiger platform was a really nice part for building a cluster. He thought of the new platform as a High Performance Server, not as a ‘part’. Well get used to it. We don’t build computers out of discreet components like transistors any more (which is good for him because Intel makes really big Integrated Circuits, not transistors) and we have just moved up to the point where the level of integration is the server, not the processor.

And Then There Were Cores
So into this environment where servers are parts and many high performance computing applications were written to a distributed memory communications aware parallel programming model, the microprocessor has changed in the most radical way I can remember. Our equilibrium has been punctuated (see: "Punctuated equilibria: an alternative to phyletic gradualism" (1972) pp 82-115 in "Models in paleobiology", edited by Schopf, TJM Freeman, Cooper & Co, San Francisco. Eldredge, N. & Gould, S.J.) and we can expect rapid change to a whole new kind of parallelism. The change I refer to is the introduction and near ubiquity of multiple core processors. For years software developers have been able to count on dramatic increases in CPU speed and processing power on a Moore’s Law schedule. But, Moore did not say that the processing speed and power of CPUs would double every eighteen months, he said that the number of gates on a single chip would double every eighteen months. So, all was good for a long time because that doubling of gates meant smaller _and_ faster gates and greater architectural complexity and thus ‘faster’ CPUs. So by about 2005, just about every good idea for a better computer processor architecture ever thought of was incorporated into the major microprocessors on the market. So, when 2006 rolled around the obvious thing to do was to use the next doubling of gates to double the number of ‘processors’ on a microprocessor. Dual core was here and the trend will continue for at least a couple of doublings. Who knows what strange beasties will emerge when we get to the point where ‘many core’ processors become ‘too many core’ processors. Until then, though we can be sure: Multicore killed the serial star....

More on this tomorrow.

Port 25: The Open Source Community at Microsoft : HPC, Frank Chism

Code Parallel or Die, Part 2

Code Parallel or Die