C or LabVIEW?

[PaulG.]

I have been in an ongoing debate with a customer about which is better for a high-speed DAQ system. I know this room is biased, but what is the answer? Can I develop better performance programming it in C? Or is LabVIEW just a good? Be honest .

[AnalogKid2DigitalMan]

May very well be dependant upon the application specifics and the skill level/experience of the programmer writing the code.

[K C]

I saw an article this week about this subject with a comparison for different applications. As analo... said it depends on many things. I always say use the tools your good at.

Tomorrow (when i am back at the office)  I will let you know where you can find this article.

[tbob]

Speed of execution will also play a part.  You mentioned high speed DAQ.  How high is high speed?  You can fine tune C to optimize speed, call assembly language procedures, and such.  You can also do this to some extent in Labview, but not as much as with C.  Of course Labview is a much easier way to go since NI has all the DAQ drivers written for Labview.  Writing this in C will take a much longer time, and will be much more difficult to maintain.  I would think that speed would be the main decision maker.  If Labview is fast enough, it is the most logical choice because of ease of programming and maintenance (assuming there is someone there familiar with Labview), which in turn provides cost savings due to shorter development time and cost savings for maintenance for the same reason.

[K C]

This is the link to the LV -- C benchmark.

http://zone.ni.com/devzone/conceptd.nsf/webmain/DC9B6DD177D91D6286256C9400733D7F 

[PaulG.]

This specific application would be for digitizing 20usec worth of data at 1 Gs/sec (8 bit) at 400Hz intervals. Drivers are available for the board in C and LV. We would also have to display the waveform along with software-generated data gates, i.e. where we are actually acquiring the data on the waveform.

Paul

7.1/XP

[PaulG.]

Thanks for the link. I was hoping that maybe a few of you had real-world experience developing applications in parallel, one in C and one in LV for benchmarking purposes. I love LV and never want to go back to C. LV's performance increases with each new release, but there is still a lot of concern in the industry, especially in high-speed data acuisition applications that LV still can't quite keep up with C.

Paul

7.1/XP

[Chris_Cilino]

All,

I think this is a great topic! As a matter of fact, I'm currently rewriting the document that's already been referred to in this forum and updating it for LabVIEW 8: Benchmark Execution Speed of LabVIEW Applications. The article should be updated in the next few weeks so keep your eyes pealed!

There is another great article that compares LabVIEW to C, called Can LabVIEW C?. This article aims at showing the power and flexibility of LabVIEW and even contains a number of example programs and links to other documents. I'll summarize by saying that this article is FANTASTIC!!!

Another source of information on LabVIEW is the LabVIEW Technical Information Page. Talk about information heavy! It has everything from "Software Engineering and Code Reuse" to "LabVIEW as a Programming Language" and you can easily spend hours reading.

I think that one of the best conclusions is that LabVIEW can save developers hours upon hours of development time. If some applications do run faster in C, the time and money saved during development by using LabVIEW far outweighs the milliseconds saved during execution of the code. Its worth noting that in the instances where C outperformed LabVIEW, it WASN'T by orders of magnitude. In the worst case, C was less than 1.5 times faster than LabVIEW.

Keep the debate alive!!! Its a very worthy question...

Best Regards,

Chris C

Applications Engineering

National Instruments

[DFGray]

This data rate (8MBytes/sec) is not terribly difficult by itself.  You can easily do 20MB/sec or more with a standard desktop PC while saving to disk (provided the disk can keep up) using NI-SCOPE boards.  You may want to start another thread or post details in this thread.  From your brief description, it appears your problem can be done in LabVIEW, although it will not be trivial.  You will probably need some not-so-obvious optimizations.

To add my 2 cents in to the original question, LabVIEW is usually fast enough for most applications.  However, in most applications, a well written C app will outperform a well-written LabVIEW app. It won't be a huge difference (2X or better) and the C will probably take a lot longer to code (depends on the skill levels of the C and LabVIEW programmers) and be harder to maintain.  I have programmed in C, C++, BASIC, assembly, FORTRAN, and LabVIEW and much prefer LabVIEW, despite its minor speed hit.  Note that these comments apply to standard LabVIEW only.  Other versions, such as FPGA, do not have the same speed problems.  From the benchmarks I have seen, a VHDL vs. LabVIEW matchup would probably end in a draw.

[Ben]

Ditto all of the above.

I have not done the side by side LV vs C BUT I did consult on an NDT application with similar specs.

Doing the live updates was the challenge the customer faced and we managed to pull that off.

in my book "High-speed" DAQ is when the raw data transfer rates approach the bus transfer rate. In those applications I can easily "divide and conquer" and distribute the application across multiple platforms.

I shuder at the thought of having to do the same thing WITHOUT LV.

Ben

Message Edited by Ben on 10-28-2005 03:05 PM

Message Edited by Ben on 10-28-2005 03:06 PM