Performance Comparisons

[h1voltage]

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

[Yair]

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.

[h1voltage]

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

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.

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?

[daal]

There is some improvement to get good result

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

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

Dany

[Ton Plomp]

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

[Yair]

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

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

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.

[h1voltage]

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?

[Yair]

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.

[h1voltage]

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.

[Zbyszek]

QUOTE(h1voltage @ Jun 22 2007, 04:23 AM)

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

I think the difference derive from facts that in each case you use different type of values (integer/float). Compiler have possibility to optimize first part as integer (100 != 100.0). But I still recive difference even if I use: (x+1.0)*2,0833333333333333333333333333333=<100./(16.0*3.0)>. I ment that compiler optimize this formula to this equation.

QUOTE(Zbyszek @ Jun 29 2007, 09:54 AM)

Ok. I get it. You need to use shift register. If you don't use it then compiler have posibility to put in formula place constant value. I don't know why compiler didn't it in first loop. Now results are the same.