Jump to content
Sign in to follow this  
h1voltage

Performance Comparisons

Recommended Posts

Hello everyone,

I have searched this forum and the NI forums for benchmarking, and have found only bits and pieces. Has anyone compiled a list of performance comparisons? For example, I made a little test loop to time the concurrent for loops doing the same numerical operation using the native mathematics VIs and the formula node (timing VIs courtesy of Mark Balla - http://forums.lavag.org/probe-with-timesta...html&p=2359 It turns out that the formula node is faster.

http://forums.lavag.org/index.php?act=attach&type=post&id=6161

These are the kinds of things that would be nice to know when doing tight, efficient coding. I must admit, however, that the time difference in this case is almost neglible until over a certain number of loops. However, I am sure that there are more significant examples. Would anyone care to share some of his or her experience using different methods to make significant performance increases?

On the note of benchmarking, I have heard that simply using a loop is not a very good comparison of speed, and that it is actually quite difficult to make accurate benchmarks. In my own experience with timing VIs, I have found that sometimes inserting another VI into the loop can speed things up (exactly the inverse of what I would expect). What other ways can be used to determine if certain coding methods are more efficient?

~Zack

http://forums.lavag.org/index.php?act=attach&type=post&id=6163

Share this post


Link to post
Share on other sites

There are two issues with your timing - one minor and one more significant.

The minor issue is that there is no gurantee that the timing VI will run before the loop starts. This is minor because at most you will miss a small number of loops, but it's still wrong.

The more significant issue is that you are timing both pieces of code at the same time which is bad, because you have no way of knowing what the LV scheduler will do. You should test them under equal conditions, meaning having a seperate VI for each.

When I did that, the formula node was still faster, but by a smaller margin.

I could see how in certain conditions adding a subVI could improve speed, because the algorithm responsible for allocating memory might decide to reuse a buffer instead of duplicating data, but I would expect that would only be under fairly rare circumstances.

Share this post


Link to post
Share on other sites

QUOTE(yen @ Jun 19 2007, 05:08 PM)

Does this mean run them completely seperately or as subVIs? If it is completely seperate, there is also no gaurentee that the processor / OS is in the same state (memory, CPU load) on one VI verses the other.

QUOTE(yen @ Jun 19 2007, 05:08 PM)

I could see how in certain conditions adding a subVI could improve speed, because the algorithm responsible for allocating memory might decide to reuse a buffer instead of duplicating data, but I would expect that would only be under fairly rare circumstances.

I have gotten a similar explaination to this before. Can you explain how this works a bit further?

Share this post


Link to post
Share on other sites

Moving the calculations of the for loop into one math-node will speed things up as well:

http://forums.lavag.org/index.php?act=attach&type=post&id=6169

I was surprised it even took time to calculate, because the compiler knows the answer beforehand!

So I changed the constant 5 to a control:

http://forums.lavag.org/index.php?act=attach&type=post&id=6168

Things were just a little bit slower.

Ton

Share this post


Link to post
Share on other sites

QUOTE(h1voltage @ Jun 20 2007, 01:23 AM)

LabVIEW uses an algorithm called the inplaceness algorithm which is used to decide when LabVIEW can avoid making a copy of data which is found on a wire and instead schdule the execution in such a way that it can use the same buffer for more than one operation. Since memory allocation is expensive, this is an important performance enhancement. Have a look at http://forums.ni.com/ni/board/message?board.id=170&message.id=191622#M191622' target="_blank">this thread for an example of how changing a subVI can affect the memory allocation in the caller.

LabVIEW used to ship with a white paper about performance and memory management (available through Help>>Search the LabVIEW Bookshelf), and that had some more examples and details, but I don't know whether it still ships with it. It's probably available on NI's site as well.

Share this post


Link to post
Share on other sites

No one has really answered the question that I wanted to know the answer to: has anyone compiled statistics on LV performance in various coding situations?

Share this post


Link to post
Share on other sites

QUOTE(h1voltage @ Jun 21 2007, 04:47 AM)

has anyone compiled statistics on LV performance in various coding situations?

Probably not. People may have done this for specific situations, but unless you have to squeeze every last microsecond from your CPU you usually focus on making the code cleaner and on the big speed\memory improvements, which are fairly standard.

NI probably does benchmarking as part of their R&D process, but I doubt they would make that public.

BTW, that application note I mentioned is app note 168.

Share this post


Link to post
Share on other sites

QUOTE(yen @ Jun 21 2007, 11:35 AM)

Probably not. People may have done this for specific situations, but unless you have to squeeze every last microsecond from your CPU you usually focus on making the code cleaner and on the big speed\memory improvements, which are fairly standard.

NI probably does benchmarking as part of their R&D process, but I doubt they would make that public.

BTW, that application note I mentioned is app note 168.

Thanks for your reply. I'll check out the app note.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.