View Single Post
  #54   Spotlight this post!  
Unread 05-04-2010, 21:27
Greg McKaskle Greg McKaskle is offline
Registered User
FRC #2468 (Team NI & Appreciate)
 
Join Date: Apr 2008
Rookie Year: 2008
Location: Austin, TX
Posts: 4,756
Greg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond reputeGreg McKaskle has a reputation beyond repute
Re: PROGRAMMERS: WIND RIVER C++ vs LABVIEW vs JAVA

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