06-08-2013 12:02 AM
Is there an article out there that compare the speed of C and LabVIEW on common tasks? Thanks!
06-08-2013
02:17 AM
- last edited on
04-16-2025
03:37 PM
by
Content Cleaner
What prompted your question? Do you have a performance bottleneck in your LabVIEW program? Often you can gain an order of magitude by optimizing the program for better inplaceness and more concurrency.
I think there was an application note very long ago, and the speeds were similar, but I cannot find it anymore. Since then, the LabVIEW compiler has seen many advances.
Especially if you want to leverage the power of moders CPU with multiple cores, LabVIEW has a huge advantage due to its inherent parallel nature. You can have a look at e.g. the comments in this old discussion.
As with anything, the skillls of the programmer are probably more important. A C programmer most likely has a more solid programming background, while a beginner LabVIEW programmer might even have problems understanding hexadecimal. Here in the forum we often see relatively poorly written and poorly performing LabVIEW program that use 100% of the CPU just waiting for user input. Of course having a beginner be able to write a marginally functioning program is orders of magnitude better than having him try the same in C and nothing would ever come out of it.
In computing, "common tasks" (your words!) are processing tiny amounts of data and waiting for user input, and speed is completely irrelevant. One of my early LabVIEW 4.0 program still runs fine on a 120MHz Pentium 1, which is orders of magitude less powerful than even your smartphone. OTOH, doing some serious processing (e.g. a huge matrix inversion or 2D FFT) uses code that is highly optimized in LabVIEW and probably comparable to any C code (which probably uses very similar libraries, e.g. Intel MKL). (if you need to go even faster, spend $10k on some serious computer hardware with many processors and do a drop-in replacement with the "NI LabVIEW Multicore Analysis and Sparse Matrix Toolkit". ;))
A skilled LabVIEW programmer should be able to keep up with any C code where it counts. The LabVIEW program might even perform better on multicore hardware with no extra effort. For example, my LabVIEW based program for spectral fitting is 17x faster on my 16(32) core dual Xeon machine compared to the performance using only a single core (details). It would take significantly more skill and effort to achieve a similar scaling in a C based program. Not impossible, but very hard. 😮
An equally important benchmark is how long it takes to write a functional program that includes an interactive user interface and all specified features. Here LabVIEW wins hands down, of course! 😄
06-08-2013 12:32 PM
I am trying to convince the management that a C-based program can be re-written in LabVIEW without sacrificing speed. When I said common tasks, I was thinking about common tasks in automation, such as serial communication, GPIB communication, file read/write, large array manipulation, etc.
06-08-2013 01:39 PM - edited 06-08-2013 01:47 PM
We had done some in-house speed performance comparisions on a project that was converted from C-based to a LabVIEW design (Windows platform) and performance was actually improved - probably because several items were replaced with native LabVIEW functions which are already quite optimized. In fact so far we have only seen LabVIEW usage at disadvantage in case of low-power ARM based/Embedded platforms.
Your bigger argument in convincing your management might be that not only LabVIEW will run faster in most cases, but it will also cost them less to develop with an added bonus of much shorter time-to-market. And as Altenbach mentioned, LabVIEW blows away all other development suites in ease of creating a rich graphical user interface! If you are someone who has worked with VisualStudio/Eclipse/Xcode/etc, you'll be quite familiar with how long it takes to create or change graphical interactions - LabVIEW does all that significantly faster.
-DP
BatchTest Corp.
NI Alliance Partner
06-08-2013 08:27 PM
I need some hard data to convince them. It is hard to convince a C programer of that.
06-08-2013 08:43 PM
In all the "common tasks" you mentioned except large array manipulation, the limitations will be the communications hardware and the disk hardware. Those programs would likely run just as well under LabVIEW 1.2 on a Mac SE. Of course the 10 MB hard drive in that computer was much slower than today's disks.
If you have a well defined array manipulation task which is already running in the C program AND you can accurately time its performance in that program, then ask to have HALF as much time as the C programmer(s) used to write that routine to write LV code which performs the task. Run both on the same test data sets and see how the time compares. This is probably a task for which you will see very little performance difference running on a single core. As Altenbach pointed out you may get substantial performance improvements on multicore systems.
Lynn
06-09-2013
06:32 AM
- last edited on
04-16-2025
03:37 PM
by
Content Cleaner
To add to the comments above:
There are some examples and case study in this whitepaper http://www.ni.com/white-paper/2718/en.
I would also consider the development time.