LabVIEW 8.5 serves power of multi-core
01 November 2007
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. Today, increasing clock speeds for performance gains is not viable because of power consumption and heat dissipation constraints. Chip vendors have moved to entirely new chip architectures with multiple processor cores on a single chip. With multicore processors, programmers can complete more work than with one core alone. However, to take advantage of multicore processors, programmers must reconsider how they develop applications. Developers can no longer expect to see immediate software application performance gains when end users simply upgrade computers to ones with faster processors.
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, developers need to design their applications to divide the work among cores; in essence, develop a parallel application instead of a sequential one.
National Instruments LabVIEW software is well-suited for engineers and scientists to exploit the processing power of multicore chips. Firstly, it is a graphical, dataflow programming language. Developers can visualise parallel tasks in LabVIEW, making it possible to develop new applications and modify existing applications to take advantage of multicore processors. LabVIEW has been multithreaded since Version 5.0; Version 8.5 introduces new enhancements for multicore processors.
Secondly, it brings multicore performance to embedded real-time hardware. LabVIEW 8.5 brings the automatic multitasking capability found on desktop operating systems such as Windows and Linux, known as symmetric multiprocessing (SMP), to deterministic, real-time systems.
Finally, LabVIEW sits on top of a multicoreready software stack. Each layer of a LabVIEW application (for example, LabVIEW application code, low-level functions, and I/O drivers) is thread-safe to take advantage of multicore processors.
Graphical, dataflow programming
The main benefit of developing an application in LabVIEW is the intuitive, graphical nature of the language. Engineering problems are solved as if by drawing a block diagram on paper. For modern multicore processors, LabVIEW has the ability to express and execute tasks in parallel.
The dataflow nature of LabVIEW means that any time code has a branch in a wire, or a parallel sequence on the block diagram; the underlying LabVIEW compiler tries to execute the code in parallel. This is called ‘implicit parallelism’ because code does not have to be specifically written with the purpose of running it in parallel; the graphical language of LabVIEW takes care of a certain degree of parallelism on its own.
LabVIEW programmers naturally represent their solutions in parallel. Initial benchmarks of common LabVIEW applications, without regard to multicore programming techniques, show applications achieving 15 to 20 per cent performance improvements with no changes to the code.
The image shows an example of a simple application in which one branch in the LabVIEW code facilitates two analysis tasks: a filter operation and an FFT (fast Fourier transform) for parallel execution on a dual core machine. As both tasks are computationally intensive, the improvement from executing on one core versus two cores is an increase of 1.8 times.
Developers using traditional text-based tools must use complex coding structures, called threads, to implement parallelism in these sequential languages. Managing these multi-threaded applications can be a challenge. In C, it is managed by synchronisation through locks, mutexes, atomic actions, and other advanced programming techniques. When multiple threads become hard to follow, common programming pitfalls can arise, such as inefficiencies due to too many threads; deadlock, where threads become stuck waiting and cannot proceed processing; race conditions, where 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; and memory contention, where multiple threads try to access memory at the same time.
After code development, another example of increased productivity is the ability to perform basic debugging in LabVIEW with highlight execution and probes.
When commenting on LabVIEW for multicore development, Scott Sirrine, lead product engineer at Eaton Corporation, said: “The fact that LabVIEW is a dataflow language with automatic multithreading presents two key advantages over other programming languages – development productivity and execution performance.”
There are still cases in which system performance is further improved by employing optimisation strategies in the code. Three example strategies are: task parallelism, dividing the program into parallel executing tasks; pipelining, dividing sequential algorithms into equal stages that are split among multiple cores; and data parallelism, dividing large data sets into subsets and operating on them in parallel. (Examples of each of these optimisation techniques can be found at www.ni.com/multicore).
Real-time embedded hardware LabVIEW 8.5 brings the automatic multithreading scheduler from the desktop to deterministic, real-time systems. The LabVIEW 8.5 Real-Time Module adds multicore system support. It can perform automatic load-balancing across multiple cores on embedded real-time systems, for example. For time-critical sections of code, timed loops can be assigned to specific processor cores (processor affinity) to isolate key sections of code in a timed loop structure from the rest of the application. With the Real-Time Execution Trace Toolkit 2.0, the threads and processor cores, upon which the VIs are running, can be visualised to fine-tune real-time systems for optimal performance.
Intel has defined four layers of the software stack to be evaluated to determine readiness for multicore development. They are operating system, device drivers, applications/libraries and development tools. Parallel programs do not run faster on multicore systems if the libraries and drivers used are not multicore-ready or if the operating system cannot load-balance tasks across multiple cores.
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. NI-DAQmx, the re-engineered modern DAQ driver, is re-entrant, meaning multiple DAQ tasks can execute in parallel without blocking threads in a truly parallel fashion. The driver runs multiple tasks in parallel on the same board, such as analogue and digital I/O independently.
Parallel programming language
Engineers and scientists looking for faster measurements for test, or improved loop rates in control applications, need to consider how to implement parallel applications. LabVIEW’s software environment is ideal for parallel programming because of the dataflow nature of the language, multicore support for embedded platforms developed with LabVIEW Real-Time and a top-to-bottom multicore-ready software stack.
JEFF MEISEL is product manager for the LabVIEW Real-Time Module, National Instruments.
To learn more about implementing solutions using these techniques in LabVIEW, visit www.ni.com/info and enter nsi7301.
Contact Details and Archive...
Related Articles...
Most Viewed Articles...