Vince Hauber

Subscribe to Vince Hauber: eMailAlertsEmail Alerts
Get Vince Hauber: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: MultiTouch Developer Journal, AMD Virtualization Journal

Multi-Touch: Article

Multi-Core Debugging and Performance Enhancement

Additional pressures on complex applications

Identifying and fixing deadlock and livelock situations requires a good debugger. In today's multi-core multiprocessor environments, efficient debugging requires the user to navigate between processes and threads from a common environment without disturbing the program running. A debugger should operate with minimal application intrusion so that deadlock and/or livelock can be identified and fixed in real-time (e.g., applications hot-patched while the application is running). Users should also be able to stop a thread and observe the state of all the other threads running in the application.

In some cases, the events leading up to a lock situation may not be immediately apparent to a debugger or the exact timing will have to be recreated without a debugger present. To resolve these issues, it's often necessary to generate program execution traces so that actual events and interactions between threads can be examined.

A graphical event analyzer tool is ideally suited to this purpose. With such a tool, user programs and the Linux kernel can be traced live or viewed in a post-execution file. In both cases, user and kernel events can be collected from the multiple processes executing simultaneously on multiple cores and processors, and then examined to determine what caused the lock.

Race Conditions
A race condition is similar to a deadlock but can cause more subtle problems. Suppose the programmer in the example above only allows Process 1 to own the lock on Total to avoid deadlock. Now suppose all program threads can lock and add to the Sub-Total variable. If Process 1 decides to add the Sub-Total to Total at some point, it may not have all the contributions to Sub-Total. These types of situations can be hard to identify and result in the program providing different answers when using the same data.

A race condition is particularly difficult to find. Often they result from subtle timing assumptions in the program that aren't guaranteed to be true each and every time. The program will occasionally provide the wrong result. Moreover, when the programmer adds some debugging code or attaches a simple debugger and steps through code, the problem goes away. This type of behavior is often called "non-deterministic" since it "just happens" from time to time. To find these kinds of problems, a debugger must be able to examine program execution in real-time.

Again, a robust Linux debugger that allows real-time modification and monitoring of an executing program is essential to resolving race conditions. There's no need to add code or alter program behavior to find and repair problems. Another useful debugging feature is the ability to analyze and display memory allocations and de-allocations. A race condition, and deadlock/livelock for that matter, can occur when a thread behaves unexpectedly and memory management issues are often the source of such problems.

Mismatched Communication/Synchronization
As simple as it sounds, mismatched communication is often the cause of many parallel computing problems (both with threads and message passing). Communication is an essential part of parallel programs. (If parts of the program don't communicate then it would not be a parallel program!) Communication can also be used as a synchronization method. For instance, a thread may wait until another thread tells it to start or stop a task. This kind of communication is often called "blocking" and provides the programmer with some synchronization points.

The other method of communicating is called "non-blocking." In this method a task may be busy computing and occasionally checks to see if a message has arrived. While this asynchronous behavior can be more efficient than a synchronous blocking approach, it's also subject to communication deadlock and race conditions.

In either case, a communication mismatch occurs when a sender or receiver isn't available. These situations can occur by outright programming error or by using asynchronous methods like "non-blocking" communication. Similar to race conditions, asynchronous communication issues can be non-deterministic.

One way to debug communication/synchronization issues is to use a multi-thread event analyzer. This tool lets system and user-requested events be logged from multiple processes executing simultaneously on multiple processors or cores. The result is a minimal-overhead, high-resolution trace of your application behavior.

Taking Debugging to the Next Level
All of these conditions require the programmer to debug the programs deeper than ever before and at the same time touch the program very lightly. Many standard debuggers aren't prepared for this level of interaction. Indeed, the problems associated with multi-core debugging usually require attacking the problem using both debugging and tracing methods. Desirable debugging features are the ability to debug multiple processes in a single session, allowing runtime program modification and patching. Beyond interactive debugging, both data and event tracing offer the lightest way to touch a multi-threaded program.

Program Performance
There are many parameters that contribute to overall program performance. On multi-core systems, it's important to sort out the performance issues by application and by thread. In addition, multi-core versions of your software should work faster than a single-core version. Often programmers are stumped when they achieve poor performance on parallel systems. Having the right tools to drill down into the processor and cores is essential if bottlenecks are to be identified.

Load Balance
The most obvious issue with multi-core processors is to make sure all your cores are busy and work is balanced across them. An unbalanced application will result in poor performance improvement because one core (or thread) has become the slow step in the process. For this reason, it's important to know "what's running where?" and "how resources are being used" to eliminate bottlenecks and ensure optimum performance.

Besides load balance, there are other parameters that can indicate how well a core is performing. Monitoring imbalances in parameters like context switches, interrupts, memory paging, and processor affinity can also indicate poor performance.

A Linux performance tuning utility can aid significantly in system and application tuning. It's ideally suited for multi-core application analysis because it allows the user to probe by process and thread while observing key system metrics that can influence performance. Information can be displayed for individual processor cores so that the real-time load balance can be observed while the application is running.

Viewing Performance
A program running on single-core processors can be viewed as a progression of events dictated by the programmer. Fleshing out performance issues often requires programmers to look at the events in detail. Multi-threaded codes running on multi-core environments often have deeper issues that could not exist on single-core processors. These deep issues often involve timing between threads and the resources they touch. One way to go deep into program behavior is to instrument a program so that detailed performance data can be harvested. In preserving exact runtime behavior, user-written instrumentation can be difficult and introduce further issues in the code (or hide issues as well). It's often best to use a tracing library that's been specifically designed for this purpose.

During program operation, an instrumented program should emit trace data that's collected with minimal influence on the running program. After the program finishes, a trace file that contains the runtime information will provide insights into program and thread behavior. Another important area that is often neglected in program tracing is the operating system. Often serious bottlenecks can be traced to certain tunable aspects of the Linux kernel and thus are hidden from the end user.

Trace files can produce extremely large amounts of information when multiple cores are involved. So is it important to use a tool that can sort through the trace information easily so that critical points can be identified.

As previously mentioned, a Linux trace utility that's aware of both user application and kernel-level activity can provide a level of information not obtainable with ordinary debuggers. This information can also be used to enhance the performance of the application. Users generally know the critical parts of their programs and the trace tool can provide a detailed window into these areas. A well designed GUI front-end can also provide easy navigation through the trace data.

When developing multi-core code, the following recommendations will assist in faster and better code generation.

1)  Create a reference sequential program that can be used as a baseline for both results and performance.
2)  Use your reference program as a basis for your threaded program and make the number of threads tunable so that your program can be easily collapsed to one thread.
3)  Use a real-time debugger that preserves the timing of your program. Additional tools beyond debuggers that provide data and event tracing may be needed to ferret out difficult issues.
4)  Once the application is running correctly, examine the load and resource use by using a system/application tuner and event analyzer.
5)  As a final step, check your assumptions. The current x86 64-bit architectures all run the same binary codes, but have widely varied hardware implementations. Some time invested analyzing your program with regard to these areas will be well spent.

The speed increase offered by multi-core designs has become an exciting part of software creation. When writing and debugging code for multi-core systems, however, attention must be paid to new issues that weren't present before. Lock and race conditions can be particularly difficult to resolve with tools designed for single processors. Furthermore, improved performance isn't always guaranteed and may require deeper analysis of runtime behavior than was needed in the past.

Finally, it can't be stressed enough that as hard as single-processor programming can be, multi-core can be much more difficult. A good set of tools is essential to controlling costs and achieving delivery schedules.

The following sources can be consulted for general information about multi-core hardware and software. The Internet is a good source of additional information as well.

  • Concurrent Computer Corporation. "Preparing for the Revolution, Maximizing Dual-Core Technology."
  • Philippe Paquet. "Debugging Concurrency."
  • Herb Sutter and James Larus. "Software and the Concurrency Revolution." Microsoft ACM Queue vol. 3, no. 7. September 2005.

More Stories By Douglas Eadline

Dr. Douglas Eadline has over 25 years of experience in high-performance computing. You can contact him through Basement Supercomputing (

More Stories By Vince Hauber

Vince Hauber, a senior product manager with Concurrent Computer Corporation, has over 40 years experience in system software and platform solutions. Concurrent is a leading provider of real-time Linux distributions and tools.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.