LabVIEW program execution time on a multicore computer depends just as much on the program as on the computer running it. The program must be written in such a way that it can benefit from the unique environment presented on multicore systems. The degree of program parallelism has a large effect on program execution time, as does granularity (the ratio of computation to communication) and load balancing. A large amount of existing G code is written for sequential execution; however, this type of code likely has some inherent parallelism due to the nature of dataflow programming. As stated previously, tests of common LabVIEW program structures show, on average, a 25 to 35 percent improvement in execution time when moved from a single-core to a multicore system. The nature of an individual program, however, significantly affects this estimate. Optimizing a LabVIEW program for a multicore computing environment can result in large execution time reductions when upgrading to a multicore computing system.
Organizing G code to increase execution speed is complicated when you do not know the hardware on which you are executing the program. Understanding the system a multicore program is running on is vital to achieving maximum execution speed. Multicore programming techniques require a more generic approach for systems with an unknown number of cores. This approach helps ensure some execution time reduction on most multicore machines but may hinder maximum execution speed on any specific system. Hardware-specific tuning of LabVIEW programs can be time-consuming and is not always necessary; however, it may be necessary if you require maximum execution speed on specific hardware. For example, to fully use an octal-core computing system, you can employ advanced parallel programming techniques such as data parallelism or pipelining. Additionally, you can take advantage of the number of cores on a system, the core layout (two dual-cores or one quad-core), the connection scheme, the memory scheme, and information about known bugs to achieve minimal program execution times on multicore systems.
For more information about parallel programming strategies, refer to:
Software Stack Readiness
Bottlenecks in parallelism may arise at several levels of the software stack; avoiding this problem is a challenge in traditional languages such as C. An advantage of LabVIEW programming is the “multicore ready” software stack, which removes these bottlenecks up front. To realize the performance gains that are possible with multicore hardware, the software stack has four layers that you must evaluate to determine multicore readiness – the development tool, libraries, device drivers, and the operating system. If these layers are not multicore ready, performance gains are unlikely, and performance degradation may occur. Table 1 shows how LabVIEW ensures a multicore-ready software stack.
Multicore systems with libraries and drivers that are not multicore ready or operating systems that cannot load balance tasks across multiple cores do not execute parallel LabVIEW programs faster.