Today’s post is part of a series exploring areas of focus and innovation for NI software.
Today’s Featured Author
Jeff Phillips considers LabVIEW as essential to his day as food, water, and oxygen. As senior group manager for LabVIEW product marketing at NI, Jeff focuses on how LabVIEW can meet the changing needs of users. You can follow him on Twitter at @TheLabVIEWLion.
The light switch—that little component of our lighting system that is afforded no delay, no ramp time, and no warm up routine. When you flip up that switch, you expect to see light immediately. This expectation is the result of years of mental conditioning; however, many fail to understand how it actually happens.
What’s the light switch for LabVIEW developers? It’s the compiler. It’s that tiny run arrow button that switches your code from edit mode to run mode. Again, many years of mental conditioning force you to expect the immediate translation of your code into executable action. But do you understand what actually happens?
The run button isn’t the action that spawns the compiler down the magical world of optimizing, unrolling, and memory managing. The LabVIEW compiler is constant; it’s always on and compiling your code. From a usability standpoint, this is one area that makes LabVIEW so engaging. Our brains live off the dopamine hits of being right, solving problems, and answering questions. With each incomplete step of your code development, the compiler visually warns you that your code won’t run. Obviously, the next step is to fix that. Alas! The run button is complete again.
And LabVIEW says, “you’re welcome” for that adrenaline rush you just enjoyed—perhaps even subconsciously.
Unlike other languages where the compile is an explicit step that you take when you’re done and ready to run, LabVIEW does this action constantly. This always-on compiler streamlines the development process for programmers.
I can’t summarize the complaints I get from LabVIEW users about the compiler, because, frankly, I just don’t get them. Yes, I hear a lot about the need for by-reference classes and generics, but those are more language implementations and not specific compiler complaints. Subtle, but I’ll consider it accurate just so I’m right.
As we continue to iterate, improve, and evolve the LabVIEW compiler, our focus is on two places: writing code faster and writing faster code (this gem of language genius came from one of our senior LabVIEW architects, Darren Nattinger, also known as the fastest LabVIEW programmer on the planet).
Write Code Faster
LabVIEW was designed for engineers and scientists. The semantics of writing graphical code maps directly to most engineers who lay out solutions in their minds (see any of the maps I drew on napkins, before I was blessed with a smart phone).
We’ve had a significant focus over the last few years on reducing mouse clicks and keyboard strokes. This is one measure of an engineer’s productivity—getting to final code in minimal physical effort (right-click shortcuts, default wiring options, and so on).
Sneak Peek: As you’ll see in the upcoming release of LabVIEW (at NIWeek perhaps?), these types of improvements are continuing.
In addition to these critical improvements in the compiler, we’re investing in areas that carry this benefit into other product areas. I previously discussed one such example in the realm of hardware discovery and configuration. But, we’re also looking to extend into other areas such as managing deployed systems, simplifying data communication, and introducing other language components.
Write Faster Code
The optimizations introduced in LabVIEW 2010 with the new DataFlow Intermediate Representation (DFIR) and integration of off-the-shelf compiler technology in the Low-Level Virtual Machine (LLVM) has drastically increased the run-time performance of code without requiring rewrites of the code itself.
This compiler overhaul has laid the groundwork for continued innovation for both code optimization on the desktop and code optimizations within deployed targets, both real-time processors and FPGAs. The newly introduced multirate diagram in the LabVIEW Communications System Design Suite is a perfect example of this innovation—a novel algorithm representation that enables one high-level representation of a mathematical algorithm, even with different execution rates and sample counts from node to node.
This is representative of the focus on the LabVIEW compiler in a constant commitment to highly optimized code.
Sneak Peek: Again, you’ll see some very impressive performance improvements for large applications in the next release.