I’m excited to be back in Portland for O’Reilly’s Ubuntu Live and OSCON conferences! Today I’m covering the Ubuntu Live conference that focuses on the Ubuntu Linux distribution. Ubuntu has clearly taken the Linux world by storm and having a conference dedicated to Ubuntu sounds like a great idea. O’Reilly enjoys a long history of bringing together developers from all corners of globe and this new conference promises do that for Ubuntu.
I first attended James Reinders “Exploiting Parallelism with Multicore” talk where James covered the background and pitfalls of moving from a single core to a multi-core world. James set the stage nicely when he talked about Moore’s Law and why we’re moving to a multi-core world and not keeping our age old focus on making faster and faster processors. As Moore originally stated, the density of transistors on silicon keeps doubling every 18 months, even today. But three unvoidable pitfalls exist that prevent Intel from cranking out faster and faster processors:
- Power wall: We can no longer afford to double the performance of processors when they consume double the power. Electrical power consumed by computers has become the number one issue for running a data center and power friendly computers are becoming more important to organizations that operate a large number of servers.
- Memory wall: The speed of memory and the processor has always been mismatched. Processors spend much time waiting while data is fetched from RAM. If we make the processor twice as fast, but the memory doesn’t become twice as fast at the same time, we waste a lot of the processor cycles waiting for data from memory.
- Instruction level parallelism (ILP) wall: Performance of single threaded code has stalled. Current processor and compiler technologies do not allow for greater parallelism in single threaded code.
These three main factors drive the move to the multi-core computer architectures. James then continued on to outline the challenges that we face in embracing a multi-core future:
- How will it scale to N processors?
- How are correctness issues addressed?
- How maintainable is the solution we created?
In the process of moving to a multi-core future programmers will need to examine their programs and make sure that the programs have been prepared for running on multiple cores. Obviously single threaded/single process programs will not run well on multi-core systems and its time to either create more processes or better yet create task oriented threads in your applications.
However, working with multi-threaded applications brings about a whole new set of problems, such as concurrency/program correctness. Handling synchronization issues such a race conditions and deadlocks requires the use mutexes (locks), events and other threading tools. The concepts behind writing multi-threaded applications have been well explored, but they still add an extra level of difficulty to writing a program that scales well. Finally, its important to code for multiple cores, while keeping your program readable. Finding a set of abstractions to hide the ugly details on the thread focused underpinnings will be key to writing maintainable multi-core oriented programs.
So, how do you go about making your program multi-core ready? At the most basic level you can use the pthreads model (or the appropriate native threading package) and “slug it out” as James says. This approach gives the most flexibility, but a lot of thread overhead code will make it harder to maintain your code. Preferably, you should use abstractions that help in making programs/tasks thread oriented.
James suggests that new languages focused on parallel programming will provide the best solutions in the future, but it will take a long time for these languages to become commonplace. The easiest way to use abstractions today is to use an extension to an existing language like Intel’s Threading Building Blocks library, which extends C++ with new templates that support basic threading functions that allow you to prepare your application for multi-core platforms.
Once you’re armed with the right tools, you’ll need to review your application and identify CPU intensive tasks and move these tasks into separate threads. Decompose your application and spread the overall computing into many smaller threads that the OS can schedule to execute on the multiple cores.
However, James asserts that if your program asks the computer how many processors/cores the machine has, you’re probably coding the program wrong. Its best not to plan for a specific number of processors/cores — program for multiple cores, but don’t over-specialize. If you break your heavy computing tasks into a number of threads you can rely on the underlying operating system to spread the tasks out to the available processors/cores.
If your application already utilizes threads then the transition to multi-core programming won’t be a complete shock to you. But, making an application ready for multiple cores goes further than just using a multithreaded programming model. Isolating the computing intensive tasks into separate threads will be the most important challenge when moving to a multi-core platform.
