Why LabVIEW for Multicore Programming

Processor speeds have hit a wall in recent years. Moore’s Law, which states that the number of transistors on a chip will double every 18 to 24 months, still holds true as it has for the last 40 years, but it no longer translates into a linear increase in performance. Previously, chip manufacturers increased processor clock speed to double chip performance – from 100 MHz to 200 MHz and more recently into the multi-Gigahertz (GHz) range.

Today, however, increasing clock speeds for performance gains is not viable because of power consumption and heat dissipation constraints. Chip vendors have instead moved to entirely new chip architectures with multiple processor cores on a single chip. With multicore processors, programmers can complete more total work than with one core alone. To take advantage of multicore processors, programmers must reconsider how they develop applications. In the words of Herb Sutter, Microsoft software architect, the “free lunch is over” for developers who expect to see immediate software application performance gains when end users simply upgrade their computers to ones with faster processors. In short, software had it easy for a long time, but this is no longer the case.

Figure 1. Moore's Law demonstrates that processors are no longer getting faster, hence the move to more processors on a single chip from chip vendors such as Intel and AMD.

Sequential programs saw performance improvements as a result of processor clock speed increases; upgrading to a computer with a faster CPU meant that each individual instruction in a series would run faster. To continue seeing performance gains with multicore systems, you need to design applications that divide the work among cores – in essence develop a parallel application instead of a sequential one.

The main benefit of developing your application in LabVIEW is the intuitive, graphical nature of the language. In LabVIEW, you solve your engineering problem as if you were drawing a block diagram on paper. Modern multicore processors make LabVIEW an even more favorable choice as a programming tool because of its ability to express and execute tasks in parallel.

The dataflow nature of LabVIEW means that anytime there is a branch in a wire, or a parallel sequence on the block diagram, the underlying LabVIEW executable tries to execute in parallel. In computer science terms, this is called “implicit parallelism” because you do not have to specifically write code with the purpose of running it in parallel; the language takes care of a certain degree of parallelism on its own.

The theoretical performance benefit of moving from a single- to dual-core computer is a two times improvement. But how close you get to that limit is a function of how much you can make your program execute in parallel. LabVIEW programmers naturally represent their solutions in a parallel nature. Initial benchmarks of a common representation of LabVIEW applications, without regard to multicore programming techniques, show applications automatically achieving 25 to 35 percent performance improvements with no changes to their code, simply because of the natural parallelism in common LabVIEW programs.

Figure 2 is an example of a simple application in which one branch in the LabVIEW code facilitates two analysis tasks – a filter operation and a fast Fourier transform (FFT) – for parallel execution on a dual-core machine. Not shown on the diagram is benchmarking code that runs the “for loop” once in single-core mode by turning off one of the cores, and then in normal dual-core mode. Because both tasks are computationally intensive, the improvement based on this task parallelism is an increase of 1.8 times.

Figure 2. A Typical LabVIEW Application Demonstrating Inherent Parallelism Due to Dataflow Programming

Text-based languages such as C express parallel code using a special notation in the code that creates parallel tasks (that is, to create unique threads). Managing these multithreaded applications can be a challenge.

In C, you must manage synchronization through locks, mutexes, atomic actions, and other advanced programming techniques. When multiple threads become hard to follow, common programming pitfalls can arise, such as the following:

• Inefficiencies due to too many threads
• Deadlock – threads become stuck waiting and cannot proceed processing
• Race conditions – the timing of code execution is not correctly managed and data is either not available when it needs to be or the correct data has been overwritten
• Memory contention – a problem associated with managing memory usage in your code

Because of these development challenges in C, LabVIEW programmers get a greater increase in productivity than ever before.

Intel has defined four layers of the software stack that you can use to evaluate multicore development “readiness.” Keep in mind that parallel programs do not run faster on multicore systems if the libraries and drivers you are using are not “multicore ready” or if the operating system cannot load-balance tasks across multiple cores.

Figure 3. Description of a “Multicore Ready” Software Stack

An example at the device driver software layer is NI-DAQmx driver software. Traditional NI-DAQ (Legacy) is thread-safe, meaning the entire library blocks other threads from calling into it when an NI-DAQ function is called.

At first glance, this behavior may appear logical because NI-DAQ is used to control hardware, which is often thought of as a single resource. NI-DAQmx, the reengineered modern data acquisition driver, is reentrant – meaning multiple data acquisition tasks can execute in parallel without blocking threads.

With this approach, the driver can run multiple tasks independently, such as analog and digital I/O, in parallel on the same device.

At the lowest level of the software stack, the operating system, many of the leading real-time operating system (RTOS) vendors do not yet support automatic load-balancing of threads across multiple cores.

LabVIEW 8.5 brings the automatic multithreading scheduler from the desktop – known as symmetric multiprocessing (SMP) – to deterministic, real-time systems with enhancements to the LabVIEW Real-Time Module.

If you need faster measurements for test or improved loop rates in control applications, consider how you implement parallel applications. LabVIEW 8.5 adds even more features to the multithreaded capabilities of the language that were originally introduced with Version 5.0 in 1998. With LabVIEW, you can take advantage of a software environment that is ideal for parallel programming because of the dataflow nature of the language, first-class multicore support for embedded platforms developed with LabVIEW Real-Time, and a top-to-bottom “multicore ready” software stack.