The Multicore Association recently finished their 4th annual Multicore Expo show. The association was formed to foster industry standardization efforts amongst vendors including the exploration of potential multicore programming APIs. Aside from some of the most talked about reasons for the rise of multicore (power consumption, transistor geometry, manufacturing limitations, clock rates and Moore’s Law), the continuation of this expo is a good indicator of broad industry support for multicore computing and its adoption by scientific, commercial and military organizations.
Most major microprocessor vendors like Intel, AMD and Sun have already turned their fabrication facilities towards manufacturing products with ever an increasing number of cores. The variety of multicore architectures – GPU included – is expanding rapidly. In fact we may see single core processors disappear from the menu altogether in the not too distant future.
If you’re one of the few people who hasn’t heard about multicore processors or multicore programming (parallel programming), now might be a good time to brush-up. Without a plan to transition your products to multicore, your organization’s competitive advantage may be at risk. In the past, parallel programming was a little known domain occupied by of a handful of specialists and researchers working on sophisticated problems. This is no longer the case. If necessary, you must learn to create and adapt software to run efficiently on many cores. Even if you’re an old hand at parallel software construction, current multicore architectures offer a host of benefits that can translate to increased performance for existing software.
Since current commercial compilers possess a limited ability to automatically parallelize software for multicore architectures, developers must prepare to tackle multicore by learning some new skills and techniques. Until compilers become clever enough to analyze a program’s structure and content in order to make multicore-aware parallelization decisions, you are an integral part of parallelization process. Of course What to do and How to do it is very important, but Where to do it can be the difference between success and failure. Careful analysis using acquired skills and a solid methodology is the key to extracting every last ounce of parallelism from your application.
I get a lot of questions from developers asking how they can learn multicore programming – the What, Where and How. Recently I gave an invited talk to a group of performance engineers where much like Steven Covey’s Seven Habits, I outlined five steps that can help developers assess and direct their multicore efforts. I’m going to cover these five steps in a three part series on this blog.
1. What’s in your toolbox?
In any serious pursuit, it’s important to understand where you want to be in relation to where you are. The first questions should be “What role do I play?” and its equally important twin “What’s my overriding goal?”.
This slide, extracted from the talk presentation, indicates three broad categories of people and their roles. (click the chart to view a larger version):
Developers Most developers don’t need to create complex synchronization primitives or task queues themselves – in fact it’s extremely difficult and potentially counter productive. Creating low level software objects just isn’t necessary (think time-to-market, ROI focus, shrinking development budgets, delivery deadlines) and just diverts precious time and resources away from working on the project’s core problems. I’ve seen countless hours wasted by teams developing their version of a low-level, cross-platform library because they thought it was project critical or a unique piece of intellectual property. In most cases, development managers and teams in the trenches just need to know how to get their software working effectively on multicore. A basic understanding of the options, means and methods is all one needs. This typically includes some basic tools such as a nice compiler/debugger, a thread analysis tool and a thread abstraction method. More on those later.
Researchers Conversely, if you’re a scientist with special computing requirements, you’ll want to delve much deeper to understand the minutiae. Academics involved in parallel computing research may even publish their work in peer reviewed journals thereby hopefully advancing the state of the art. High-performance computing (HPC) researchers involved in unique physical simulations and visualization projects may need to develop purpose-built tools and techniques to realize peak performance when running on thousands and thousands of processing cores spread across hundreds of compute nodes.
Practitioners Some of you fall, perhaps not so squarely, into the middle ground between Developers and Researchers. You’ll need a broad background and a certain depth of experience with advanced tools and techniques on many platforms. You might be called upon to develop some time critical low-level code, a memory allocator or a kernel module. Practitioners may be responsible for overall application performance, lead the development team of a mission critical OS abstraction layer or the implementation of high-performance software like a database. These projects require more specialized methods as well as a thorough grounding in parallel programming theory and operating systems.
This three level segmentation is a good rule of thumb to help decide which tools should be in your multicore toolbox. That being said, it’s a very simple guide. If you have the time and energy it’s always a good idea to push the limits and expand your comfort zone – my advice is to learn as much as you can. You never know when working knowledge of a concept or tool might help land a new job or get a coveted promotion.
2. Body of Knowledge
Most people new to the world of parallel programming (and even some with experience) haven’t touched on any parallel/multicore programming topics during their tenure as serial software engineers. Coming to grips with the subject matter can be a daunting task and books like “Learn Multicore Programming in 21 days” don’t begin to cover it.
I’ve made an initial attempt to categorize these subjects into eight discreet subject areas. Depending on your goal you may need to acquire a familiarity with some or all of the eight areas.
- Foundations – The basic knowledge necessary to understand parallel programming
- Mutual Exclusion – Simultaneous use of common resources like memory
- Synchronization – Coordination of actions during program execution
- Algorithms/Methods – Patterns and algorithms used to construct parallel programs including the method of application
- Parallel Problems – Problems and pitfalls that arise during parallel program development
- Languages – Programming languages used to express parallel software
- Tools – Tools to help construct software, compile programs and analyze performance
- Optimization – Methods and techniques to optimize the serial parts of a program
I’ve put together a map of these major knowledge areas that I call the “Multicore Body of Knowledge”.
Click the image above for a larger version or you can download an A4 size PDF from here to print out and tack on your wall. The document is a work in progress so if you have any suggestions or comments please feel free to contact me.
We’ll cover the remaining three steps before jumping into multicore in a soon to appear blog post – stay tuned!
Technorati Tags:
Multicore, Software Development, Compilers
