Let me elaborate on the statement I made about node and diagram execution. I don't remember why, but had to cut that short.
Quote:
|
When a LV diagram executes, it executes all nodes it contains exactly once. That requires both red and green to execute. The case/switch simply decides not to execute one of its diagrams. The for loop, by contrast, executes its diagram N times. Hope that helps.
|
Completing the thought ...
The for loop and case/switch are nodes. They must execute exactly once. Normal nodes such as + represent a closed operation. There is no sub diagram to schedule for execution. The control structures in LV that bring additional scheduling structure to the language are the loop, switch, sequence, and subVI. Each of these executes by scheduling one or more subDiagrams in a structured fashion. This is the same as how a procedural language structure such a loop or case will manipulate the execution of its "body" expression.
So to be more exact, the case/switch is a node and must execute exactly once for each execution of its owning diagram. It performs conditional execution by scheduling one diagram and ignoring the rest. A loop only contains one diagram, and it performs repetition by scheduling it multiple times. A sequence contains N diagrams and enforces sequencing by scheduling then in sequence. A subVI doesn't look much like a flow structure, but it acts to coordinate the execution of the calling and called diagrams so that they behave as a procedure call.
While LV supports, promotes, and promises parallelism, it can't change the fundamental characteristics of the CPU(s) it runs on. Code such as you've drawn, with simple operators do not benefit from parallelism. They are synchronous atomic operations and one of the optimizations LV makes is actually to serialize that code to avoid scheduling overhead. The "clumping" algorithm's job is to identify when to use the parallelism expressed in your diagram and when to arbitrarily serialize it to improve performance.
The compiler does eliminate code and move code around to eliminate unnecessary operations. It has to be careful that the code is functional and has no side-effects. Also, realtime users would often prefer that we calculate both and not introduce jitter in the calculation.
Greg McKaskle