Welcome!

Open Source Cloud Authors: Pat Romanski, Elizabeth White, Liz McMillan, Rostyslav Demush, Charles Araujo

Related Topics: Open Source Cloud

Open Source Cloud: 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.

Recommendations
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.

Conclusion
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.

References
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."
    www.ccur.com.
  • Philippe Paquet. "Debugging Concurrency." www.gamasutra.com/features/20050606/paquet_pfv.htm.
  • 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 (http://basement-supercomputing.com).

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.


IoT & Smart Cities Stories
The deluge of IoT sensor data collected from connected devices and the powerful AI required to make that data actionable are giving rise to a hybrid ecosystem in which cloud, on-prem and edge processes become interweaved. Attendees will learn how emerging composable infrastructure solutions deliver the adaptive architecture needed to manage this new data reality. Machine learning algorithms can better anticipate data storms and automate resources to support surges, including fully scalable GPU-c...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
Digital Transformation: Preparing Cloud & IoT Security for the Age of Artificial Intelligence. As automation and artificial intelligence (AI) power solution development and delivery, many businesses need to build backend cloud capabilities. Well-poised organizations, marketing smart devices with AI and BlockChain capabilities prepare to refine compliance and regulatory capabilities in 2018. Volumes of health, financial, technical and privacy data, along with tightening compliance requirements by...
Predicting the future has never been more challenging - not because of the lack of data but because of the flood of ungoverned and risk laden information. Microsoft states that 2.5 exabytes of data are created every day. Expectations and reliance on data are being pushed to the limits, as demands around hybrid options continue to grow.
Digital Transformation and Disruption, Amazon Style - What You Can Learn. Chris Kocher is a co-founder of Grey Heron, a management and strategic marketing consulting firm. He has 25+ years in both strategic and hands-on operating experience helping executives and investors build revenues and shareholder value. He has consulted with over 130 companies on innovating with new business models, product strategies and monetization. Chris has held management positions at HP and Symantec in addition to ...
Enterprises have taken advantage of IoT to achieve important revenue and cost advantages. What is less apparent is how incumbent enterprises operating at scale have, following success with IoT, built analytic, operations management and software development capabilities - ranging from autonomous vehicles to manageable robotics installations. They have embraced these capabilities as if they were Silicon Valley startups.
As IoT continues to increase momentum, so does the associated risk. Secure Device Lifecycle Management (DLM) is ranked as one of the most important technology areas of IoT. Driving this trend is the realization that secure support for IoT devices provides companies the ability to deliver high-quality, reliable, secure offerings faster, create new revenue streams, and reduce support costs, all while building a competitive advantage in their markets. In this session, we will use customer use cases...