“Why is LabVIEW better than C?” As a LabVIEW Product Manager, I get asked this question a lot.
Honestly, it is the wrong question to ask. It becomes a valid question with a little nuance and application context (for example, “Which is better for this task, under these constraints?”). Without this detail, it’s like asking why bread is better than flour.
Honestly, it is the wrong question to ask. It becomes a valid question with a little nuance and application context (for example, “Which is better for this task, under these constraints?”). Without this detail, it’s like asking why bread is better than flour.
If you want to build a measurement or control system, then NI LabVIEW system design software is a tool that can save you the risk, expense, and inconvenience of building your own from low-level languages like C. I’m not suggesting that LabVIEW is a “better” programming language than C—especially considering that large portions of LabVIEW are written not only in G but also in C and C++. Rather, they have different strengths that programmers should understand to succeed.
How is LabVIEW like bread? Read on.
The
relationship between LabVIEW and C is similar to bread and flour. If
you want to make a sandwich, start with bread. If you want to bake a
cake, start with flour. Baking bread with flour from scratch can be
expensive and time consuming (especially if you just want a quick
snack), but when it comes to a cake, flour is essential. Similarly, you
might find it challenging to decide which programming language is best
for your task. It comes down to using the right tool for the right job.
C Gives You Low-Level Control
C
is often better for applications with tight resources that must be
closely managed. Since C is a relatively low-level language, it forces
you to consider and specify even the smallest details, such as memory
assignments and threads. A good programmer can use this low-level of
control to eliminate the overhead in most higher level implementations.
At this level, you can also take advantage of target architecture or
host operating system properties to achieve greater performance.
NI programmers wrote most of the LabVIEW libraries in C or C++ for this reason. Operations like file I/O and analysis are as fast in LabVIEW as they are in C because they are written in low-level languages and optimized for each of the platforms and operating systems that LabVIEW supports.
At some point, developer efficiency trumps the need for hand-optimized code. Relinquishing a little control to stand on the shoulders of those who have solved similar problems can benefit many projects in terms of quality productivity. Programming languages are constantly progressing toward higher levels of abstraction. This helps you focus on the problem at hand instead of the minutia of the computing.
LabVIEW: For Parallel Execution and Real-World I/O
No matter what the implementation language, high-level system design and low-level implementation must inevitably split.
In
measurement and control applications, programming is just one task of a
system designer. Engineers often don’t have time to keep up with or
rewrite old software to support the advancements in computing and
measurement hardware, operating systems, and so on. They add value by
figuring out how to acquire, manipulate, and present real-world data—not
by coming up with new ways to handle memory allocations and thread
pools. By using LabVIEW, you can build on top of tested, supported,
and maintained libraries of lower level code from NI. Choosing C means
you’ll need to implement, support, and maintain your own lower level
libraries or purchase them from a vendor (NI offers NI LabWindows ™/CVI software and NI Measurement Studio for this use case).
Syntax-wise,
C is optimized for sequential execution of instructions as fast as the
CPU can handle them. This is perfect for pure computation, when only one
task is being executed and instructions are more basic. The graphical
syntax in LabVIEW, on the other hand, is optimized for the parallel
execution of tasks that have real-world timing constraints.
LabVIEW is more than just a programming language and associated
libraries. When you use the LabVIEW integrated development environment
(IDE) with 3rd party NI hardware, you get a development
experience that is greater than the sum of its parts. The software is
aware of available hardware resources and can present available I/O
channels and execution targets as drop-down menus and project items. You
can prevent or catch incorrect configurations during editing, to avoid
costly, hard-to-debug runtime errors. Next-generation measurement
hardware (such as the NI PXIe-5644R vector signal transceiver) even
allows LabVIEW to redefine the firmware of the hardware to reach
performance levels that traditional, distinct programming languages and
instruments can’t.
Too
many projects end up late or over budget because people underestimate
the efforts required to stitch together parts from disparate sources.
When you use LabVIEW, your hardware drivers return data in the same
format as the analysis libraries consume, your UI widgets display
technical data in the same format that the analysis libraries produce,
eliminating the need to piece together components.
So Which is Better: LabVIEW, or C?
The answer might as well be “42.” To draw from The Hitchhiker’s Guide to the Galaxy,
the answer isn't meaningful until you know which question you are
asking or what problem you are trying to solve. LabVIEW and C are both
useful tools that, in the hands of skilled users, can solve almost any
problem: LabVIEW tends to be better for high-level test, measurement,
and control applications, and C is more apt for lower level
implementations of computationally intensive tasks.
The
next time someone asks you whether LabVIEW trumps C, feel free to
answer “42”. It may be the only response that will get the discussion
heading in the right direction.
by JoelleP
Posts
0 comments:
Post a Comment