Functional Globals in LabVIEW 8.5 – No Loop, No Joke

Posted on Friday 7 September 2007

As an April fools day joke this year, I posted a VI on LAVA that shows an implementation of a Functional Global that appears to not have any While Loop or For Loop around the Feedback Node. This trick was accomplished by making the While Loop very large (extending beyond the visible region of the Block Diagram) and coloring the loop’s border white :)

But, now in LabVIEW 8.5 you really can create a Feedback Node that is not owned by any loop! The screenshot below, shows an example of this.

Feedback Node Functional Global.png

It’s so beautifully simple :)


13 Comments for 'Functional Globals in LabVIEW 8.5 – No Loop, No Joke'

  1.  
    September 7, 2007 | 9:43 am
     

    Jim:

    Great information, this has slipped by me at NIWeek. Have you seen any performance benefits? What about simple resource benefits?

    I MUST TRY THIS!

  2.  
    September 7, 2007 | 10:13 am
     

    Matt: I haven’t done any benchmarking, yet. Maybe someone will do that and post it to the LAVA thread on the subject.

  3.  
    Ton Plomp
    September 7, 2007 | 11:33 am
     

    Yesterday Jeff Washington from LabVIEW R&D was at a LabVIEW day in the Netherlands, and talked about multicore and how to use Pipelines in LabVIEW easily.
    He showed us the following diagram (sort of):

    And he discussed that the Feedback node as we knew it wasn’t as efficient as a shift register, but he promised us that the Feedback node in 8.5 is exactly the same as a shift register

    Ton

    PS. On the way back home we travelled with Jeff and it was a really nice talk/guy

  4.  
    Jeffrey Habets
    September 9, 2007 | 2:43 pm
     

    I did a quick benchmark and it looks like the lv2 old-style still outperforms the feedback-node solution. For writing the old-style was about 2 times faster, and for reading 3 times faster.

    Jeffrey

  5.  
    September 9, 2007 | 3:19 pm
     

    Jeffrey: Thanks for posting your results. It’s too bad that there is such a huge difference in performance. I guess we’ll have to keep using the old-style for now :)

  6.  
    September 10, 2007 | 8:31 am
     

    Crossing my fingers that this is NI’s typical “Make it work, then make it fast” development style in full action.

  7.  
    September 10, 2007 | 10:10 am
     

    Matt,

    In this post on LAVA Rolf states:

    “And yes Jeff [Washington] mentioned that the original Feedback node was implemented by an intern and they had thought he had chosen to implement it simply as a folded shift register but that seems to not have been the case and that is why it was much slower than a shift register. In 8.5 however Jeff claimed that the Feedback register should in all aspects we as user could possibly measure, behave exactly as a shift register.”

    I’m not sure if Jeffrey Habets benchmark was done in LabVIEW 8.5 or not.

  8.  
    Jeffrey Habets
    September 10, 2007 | 1:09 pm
     

    I benckmarked in 8.5 (pre 8.5 it wouldn’t have been possible without a loop).

    I tested some more and noticed some varying results.. Working with a case for the write/read selection, I get the same performance for feedback-node and lv2-style. When I replace the case with a select-primitive (this effectively seems to introduce an extra memory allocation), the lv2-style wins.

  9.  
    September 10, 2007 | 1:34 pm
     

    Jeffrey: Regarding the memory allocation, have you looked at the VI’s with the show buffer allocations tool?

  10.  
    Jeffrey Habets
    September 10, 2007 | 3:45 pm
     

    Jim, yes I used the show buffer allocations tool..

    The differences in speed I mentioned in my first reply where partly caused by me using the select node in the feedback-solution (as by your example here) and a case in the lv2-style global (force of habit :-)).

    When using the select node in both solutions the lv2-style is still 1.5 times faster. When using a case as the select-mechanism, there is no difference in speed.

    I’m testing this with an array of 500000 dbl’s btw. Other (smaller) array size’s give different results, ranging from approx. 1.5 to 3 times.

  11.  
    September 10, 2007 | 4:04 pm
     

    Jeffrey: Thanks for the extra info. I have added this to the “Concerns>>Performance” section of the Functional Global page on the LabVIEW Wiki. If you would like to add to this, feel free. :)

  12.  
    Jeff Washington
    September 19, 2007 | 9:02 am
     

    Hello,
    The new feedback node was implemented by my group in LV 8.5 (and the original feedback node was implemented by my group in LV 7.0). We’ve done experiments to verify the discussions here and investigated the causes.

    It turns out that late in 8.5 we ran into incorrect behavior under certain conditions, so an extra copy was introduced to make the feedback nodes behave correctly in every scenario. This fix resulted in a performance penalty which was not present when we did performance measurements earlier in the release process.

    This is unfortunate, and we are investigating addressing this for future versions of LV.
    Correct and fast would be better than correct and slow which is better than wrong and fast.

    Jeff Washington
    Principal Engineer
    LabVIEW R&D

  13.  
    September 19, 2007 | 9:07 am
     

    Hi Jeff,

    Thanks for the fast (and correct) response ;) I’m happy to hear that you’re working on it. Is there a CAR number for this issue, so that we (the community) can more easily monitor progress?

    Thanks,

    -Jim

Leave a comment

(required)

(required)


Information for comment users
Line and paragraph breaks are implemented automatically. Your e-mail address is never displayed. Please consider what you're posting.

Use the buttons below to customise your comment.


RSS feed for comments on this post |

 

Bad Behavior has blocked 610 access attempts in the last 7 days.