PROGRAMMERS: WIND RIVER C++ vs LABVIEW vs JAVA

[Radical Pi]

Quick question: is the LV RT a bytecode based system (like Java) or is it just a run-time linked library?

[Robototes2412]

From what I've heard, its a bytecode system, but its is just a hair slower than java, and only enough to make java faster for the camera. The Java camera code is actually written in C++, which i raw machine code, being the fastest.

[wireties]

Originally Posted by Greg McKaskle

I agree with your overall post...

1990 - that long ago - now I feel old! Anyways, LabView is a great product and NI a great company. How efficient are the resulting binaries compared to code generated by commercial and open source compilers? NI does many things well but can it be that their compiler tech is way ahead of companies and open source contributors whose sole focus is compilers? Maybe so...

Why would one language be better in a multi-tasking environment than another? The VxWorks kernel and its native API are in C. Some languages (like Ada) have multi-tasking elements built into the language. I can see how they are more convenient. But you can't hide or abstract things w/o it being slower and/or less capable. Even the compiled versions of LabView must access the VxWorks API and the system call interface to interact with the OS. In any language some simple calls setup the tasks. The kernel does the multi-tasking for you w/o any further work by the application code (given a good design).

I love to use LabView for many kinds of tasks. But I would NEVER hire a software engineer to do embedded work that cannot use C/C++ effectively. Many times it is all that is available.

[FRC4ME]

Originally Posted by wireties

Why would one language be better in a multi-tasking environment than another? The VxWorks kernel and its native API are in C. Some languages (like Ada) have multi-tasking elements built into the language. I can see how they are more convenient. But you can't hide or abstract things w/o it being slower and/or less capable. Even the compiled versions of LabView must access the VxWorks API and the system call interface to interact with the OS. In any language some simple calls setup the tasks. The kernel does the multi-tasking for you w/o any further work by the application code (given a good design).

One question I've always had is this: why does this argument end at C? Isn't the entire concept of a kernel a layer of abstraction in itself? Wouldn't it technically be faster to write the machine code directly rather than call POSIX API functions?

Everyone talks about C like it is the end-all-be-all of speed and efficiency, which confuses me because C is not the lowest level and seems like a rather arbitrary choice. Forgive me if I'm totally wrong; I'm no expert at the low-level stuff.

[virtuald]

Originally Posted by FRC4ME

One question I've always had is this: why does this argument end at C? Isn't the entire concept of a kernel a layer of abstraction in itself? Wouldn't it technically be faster to write the machine code directly rather than call POSIX API functions?

Everyone talks about C like it is the end-all-be-all of speed and efficiency, which confuses me because C is not the lowest level and seems like a rather arbitrary choice. Forgive me if I'm totally wrong; I'm no expert at the low-level stuff.

You're right, C is a (mostly) arbitrary choice, but its also a language that is available on almost any reasonably popular platform. So, for some definition of 'portable', C is generally the lowest level you will get to on a computer where you're not writing entirely machine-dependent code (with some caveats, of course).

If done correctly, the general stuff you write for one platform in C will work with little to no modification on some completely different platform. With machine code, you can't do that. The other thing is that C was designed to write things that used to be written in assembly language, so to some degree that influences its design and usage.

[Tom Line]

Originally Posted by apalrd

We like LabVIEW because we can do real-time analysis of things without re-downlading. Like making graphs vs Time of data points, probing data, and changing cal points. However, the largest negative I have is the build and download times. I once timed a build at 2 mins 41 seconds. The downloads are more reasonable, at around 1 minute. Overall, I would prefer LabVIEW over C++.

Ding ding ding. This is exactly why we promoted labview to beta teams over C++ etc.

The absolute ease of creating detailed front panels that provide real time feedback of ALL your variables, sensors, inputs, etc is an incredibly powerful tool. You can do the same thing in the other languages, but not nearly as quickly or easily. The tools are already provided for you in Labview - just drop the components you want on the front panel. Not having printf's is a wonderful thing.

I agree with the builds and downloads taking a bit, 4 minutes is pushing what you can handle during eliminations.

[virtuald]

Originally Posted by Tom Line

The absolute ease of creating detailed front panels that provide real time feedback of ALL your variables, sensors, inputs, etc is an incredibly powerful tool. You can do the same thing in the other languages, but not nearly as quickly or easily. The tools are already provided for you in Labview - just drop the components you want on the front panel. Not having printf's is a wonderful thing.

I agree, having real time feedback on variables (and being able to provide that feedback as well) is an incredibly powerful tool. Thus why I created WebDMA, so you could have the same type of functionality in C++ -- incredibly simple to use. I haven't gotten around to adding graphs yet, but anyone reasonably competent in javascript could do it without too much effort.

http://code.google.com/p/webdma/

[Greg McKaskle]

Originally Posted by Radical Pi

Quick question: is the LV RT a bytecode based system (like Java) or is it just a run-time linked library?

LV RT, like desktop LV, generates native machine code -- PPC for the cRIO. It is not a VM.

Greg McKaskle

[Greg McKaskle]

Good questions. Quoted section marked with ***s.

*** How efficient are the resulting binaries compared to code generated by commercial and open source compilers?

The performance of compiled LV code varies depending on the data types and data access patterns in use. The LV compilers have traditionally been pretty simple, thus quick to target to new HW, but not as time or space efficient as more optimizing compilers. Over the last few years, this has improved quite a bit -- using LLVM internally in order to get better codegen.

*** Why would one language be better in a multi-tasking environment than another?

The C language knows nothing about threads or parallelism, those are added at the library layer. The C programmer needs to use explicit mutexes, semaphores, critical sections, and threads in order to ensure safe and correct execution in a multitasking environment. A C function foo(int a) doesn't declare how thread safe it is, it typically isn't analyzed for thread safety, and there are no keywords for marking it as reentrant, critical-section, etc.

By comparison, in LV, language features such as functions and wires are inherently multi-task-safe. By default, functions have a critical section around them, but a simple property change makes them reentrant. Each function call also allows for a priority change. Wires ensure the value read is delivered to each branch of the wire regardless of when it is executed, avoiding unwanted side effects.

So it isn't a matter of simply being better, but being more automatic and more safe. It is possible to write totally sequential LV code with no parallelism, but it is actually more natural to specify the code with dataflow parallelism exposed, which LV will then execute that way with the assistance of the OS. Similarly, it is possible to write C code that does lots of parallelism, but it is more natural to write the C code in a sequential form which will be executed with no parallelism. Compiler options for vectorizing C do exist, they have for decades, but the options are not used that commonly. Compilers for parallelizing C are more rare, are generally still a research topic, but seem to be on the near horizon.

*** The VxWorks kernel and its native API are in C. Some languages (like Ada) have multi-tasking elements built into the language. I can see how they are more convenient. But you can't hide or abstract things w/o it being slower and/or less capable. Even the compiled versions of LabView must access the VxWorks API and the system call interface to interact with the OS. In any language some simple calls setup the tasks. The kernel does the multi-tasking for you w/o any further work by the application code (given a good design).

The LV execution engine augments the OS scheduler to allow it to carry out execution according to the dataflow specification. It doesn't replace the OS threads package, but attempts to use it automatically and efficiently.

Greg McKaskle

[Robototes2412]

Then here's the question of the hour: can i write labview code in a line-based language, like python?

[Greg McKaskle]

Answer of the hour ... anything is possible, but NI doesn't provide a textual form of the language, at least not yet.

Greg McKaskle

[Radical Pi]

Originally Posted by Greg McKaskle

Answer of the hour ... anything is possible, but NI doesn't provide a textual form of the language, at least not yet.

is this a hint or something?

[MikeReilly]

Great stuff, and Greg I really appreciate your input. Sure you're from NI, but I feel you've been objective.

As a mentor, I'm bummed about the lack of growth in our programming team. We have 2 or 3 people usually doing some code, but one uber-coder who likes to pursue some ultracool stuff that most others can't keep up with.

Last year, that ubercoder had some personal issues and wasn't available for some chunks of time, so one mentor and his son learned to do just about everything in LV in a couple of weeks.

For teams that don't have an ubercoder who loves data, bits and bytes, go LV. If you have an AP Comp Sci class at your school, Java might be the way to go since you have a class of programmers at your school. For the code-jocks who like to have access to pointers and the core of code, they won't let go of C++.

But the bigger question is around the "I" in FIRST: is your goal to code, or inspire coders? For that, LV might be the biggest winner, and we're going to be making a bigger move into.

[Kyler386]

I can't say much in comparison with Java or C++, but I have threatened our LabView code into working with wire cutters...

[BEEKMAN]

Originally Posted by davidthefat

fstream it, write it into a txt file and read it after to debug... But still lots of numbers

correction, the write another C# program to make a graph of the data!!! now you have 2 languages!