c vs labview

[jyang72211]

There is a program written in C for a test system that consists of a PC, an agilent SMU, and a mechanical mover.  The program would control the mechanical mover to move the DUT to the correct location and set the SMU to the appropriate condition to perform test.  Besides controlling the equipment, the PC has to do a lot of data logging, some UI funciton, ftp, and teleneting.  The program was written in C for speed, but I don't believe it does anything with multithreading,  

I understand that C is faster than LabVIEW, but since LabVIEW can do multithreading easily, is it possible for C and LabVIEW to match in speed?  Is there an easy way to test?

[crossrulz]

---

jyang72211 wrote:I understand that C is faster than LabVIEW

---

That is a false statement.  C has the potential to run faster than LabVIEW if you know which tiny details to optimize.  On the LabVIEW side, if you know how to manage your memory well (this is the most common bottleneck I run into) LabVIEW will run as fast or faster than a C program.

Check out this article:LabVIEW or C? (Could You Rephrase the Question?) 

[johnsold]

Both the Agilent SMU and the mechanical mover will be far slower than any reasonably well-written program in LV or C. Go with what you know and what you can write most quickly.  And recall that LV was designed exactly for that kind of system.

Lynn

[JÞB]

That speed of LabVIEW vs C myth should be taken out and SHOT.  When you compare the speed of a DLL call against excution speed in the IDE it is not a comparision.

Can you even run C in its IDE? I guess that makes LabVIEW infinately faster on that comparision!  A LabVIEW built application (Debugging disabled just like the DLL you can't debug) often out performs C.  AND the compiler is always improving with new releases annually.  Any other software enviornment pushing that hard on compiler optomizations?  The effort has been paying off handsomely.

Note: both 6.i and 7.0 were outperforming C in some areas.

[jyang72211]

It is very good to know.  I guess someone down the line, I bought into the myth as well.  I am glad that someone clear that up.  Thanks!

[rolfk]

---

@JÞB wrote:

Can you even run C in its IDE? I guess that makes LabVIEW infinately faster on that comparision!  A LabVIEW built application (Debugging disabled just like the DLL you can't debug) often out performs C.  AND the compiler is always improving with new releases annually.  Any other software enviornment pushing that hard on compiler optomizations?  The effort has been paying off handsomely.

Note: both 6.i and 7.0 were outperforming C in some areas.

---

Yes. any modern Visual IDE such as Visual C will allow you to run C code right in the IDE, without requiring you to write much of a test harnass first. LabWindows/CVI and even LabWindows for DOS before that used to provide this already almost two decades ago.

As to speed between C and LabVIEW. If you truely know how to write VERY good C code you will always be able to write code that is as fast or faster than LabVIEW. But then we are talking about a level of programming experience that only very few people can achieve. At the level an average C programmer does work, it can or can not be as fast as LabVIEW. The big difference is in the level of programming experience you need to have to get something working in either language. While you won't be able to program something in C that is working at all without a decent programming level, many people without any kind of formal programming education get easily away with that in LabVIEW. Which can lead to abonimal algorithmes that do what they are supposed to do, at a terrible performance. Chances that you end up with the same kind of algorithme in C are a lot smaller, since you do need some basic programming experience already to be able to get something that does not only crash your system.

Considering similar levels of general programming knowledge, the LabVIEW vs. C speed controversy is simply a non-issue as there is no clear winner in that respect. On the other hand prototyping code in LabVIEW is definitely faster as you do not need to concern yourself about memory allocation and such things at all, that will usually put you straight into the debugger, when even a single pointer gets messed up in C.

The outperforming areas you mention were likely highly optimized analysis routines written in - gasp, yes C - by NI.

[Darin.K]

I must have missed the Kool-Aid bowl since I have no qualms saying that C is undeniably faster than LabVIEW.  The same can be said about JavaScript and Python, there really is no shame.  However, you are not giving up speed in order to have more time to get coffee, in return you get stability since LV makes you work pretty hard to reference an invalid memory location (cause of probably 95% of all crashes, if not more).  I agree with most of what Rolf said, except I do not find that it requires a particularly clever C programmer to beat LV code. 

As they say opinions are like you-know-what, everybody has one.  I use a very simple test with every new version of LV to check the state of affairs.

1.  Open the BD of the Ramp.vi (Samples).  Very simple code, a simple For Loop with some math, all done easily with basic primitives.  What do you see on the BD (as of LV12)?  A CLFN.  That tells me what NI really thinks about the speed difference.  I have old code from CINs that did the same thing because in LV2 and LV3 it took several msec just to create a ramp of 1000 integers so I have been testing this for a while.

2.  Now benchmark.  I compare the time it takes to generate a 25000 point ramp using both the Ramp.vi (CLFN) and a simple For Loop in G.  In fact, I cheat (to the benefit of G) and only convert the iteration terminal value to a DBL, I do not require the G code to do any math in the loop.

Results:

LV9:  Ramp = 120 usec, For Loop = 240 usec, Par For Loop = 354 usec

LV12: Ramp =  80 usec, For Loop = 120 usec, Par For Loop = 125 usec

So G is definitely improving, but is still significantly slower than C.  If code execution speed really matters, use C, if code creation speed matters use LV.  And either way you are more likely to screw up the algorithm which is usually far worse.  My own experience is that most times LV is fast enough, and when LV falls short it usually due to two shortcomings: very limited support for recursion and recursive data types.  The former is key for implementing many classic algorithms and the latter is key for creating efficient data structures which is often 80% of the battle when dealing with large data sets.

[Yamaeda]

I made a test VI which created 100000 element arrays 1000x and my Phenom resulted in:

Ramp primitive: 1269 ms

For loop: 1366 ms

Par loop: 836 ms

So in this case, on my computer, C and basic LV is the same, and optimized/parallellized LV code is faster. 😉

/Y

[rolfk]

---

@Darin.K wrote:

I agree with most of what Rolf said, except I do not find that it requires a particularly clever C programmer to beat LV code. 

---

What I was trying to say was more along the lines of:

A C programmer needs quite a bit more programming knowledge to be able to get a program that does something useful without possibly crashing. In LabVIEW as you say, it is very hard to make it crash, even if you have absolutely no knowledge about programming. In fact I would say that it requires some advanced programming techniques to have a good chance to get LabVIEW to crash normally.

And the most common case for slow LabVIEW programs is not that LabVIEW is slow in itself, but that very bad implementations have been done for certain algorithmes, sometimes because the most straightforward algorithme was used, sometimes because the actual programmer spagetthicoded a Rube-Goldberg solution. In either case the programmer in question most likely would never have been able to get the a working algorithme in C that would not crash.

A typical C programmer has often more formal general programming eduction and therefore is likely to come up with a more elegant and optimized algorithme than many LabVIEW programmers. And that is not to say that a LabVIEW programmer can't have a good programming education. only that you can get something actually working in LabVIEW, without really knowing anything about programming, which is rather unlikely with C.