From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
03-23-2009 11:31 AM
This is just an idle curiosity - is there a difference at any level whether you use the decrement function to subtract vs. the actual subtraction function? In tight quarters (and for small subtraction values) it's tempting to line up decrement functions to perform the desired subtraction. Is there any detriment to doing this over using the actual subtraction function?
thanks,
jimmy
Solved! Go to Solution.
03-23-2009 11:37 AM
03-23-2009 12:19 PM
MattBradley wrote:
Well, it would be slower -- but not by too much.
I benchmarked it out of curiosity, see attached VI. They are pretty much instantaneous, for the case of 10 decrements (this difference may grow with a larger difference 100, 1000..., but even using 10 decrements erases you real estate gain from not using the subtraction function).
03-23-2009 03:20 PM
Increasing it to 100 decrements makes it take 16 times longer than the subtract function (verses 8x with 10 decrements).
I'm waiting for a test to run, so I had the time...
03-23-2009 07:56 PM
jmcbee wrote:They are pretty much instantaneous,
The reason they are so fast is because of "constant folding", so very little computation is actually talking place (most calculations got done at compile time!). As it stands, the benchmark is totally meaningless.
You need to replace your diagram constants with controls and modify the code until all fuzzy wires and fuzzy structures have disappeared.
Try it, it's not that easy. 😉
With N=10000000, x=y=10, the times go from 0.05, 0.05, 0.05 (your code) to the more realistic 0.16, 0.71, 0.94 (code without folding).
Of course you also want to disable debugging (for a result of 0.16, 0.70, 0.81), because you want to measure the math, not the debugging overhead. As you can see, a FOR loop benefits more from disabling debugging than a simple subtract. Seems reasonable.
Happy benchmarking. 😄
03-24-2009 09:01 AM
altenbach wrote:
jmcbee wrote:They are pretty much instantaneous,
The reason they are so fast is because of "constant folding", so very little computation is actually talking place (most calculations got done at compile time!). As it stands, the benchmark is totally meaningless.
You need to replace your diagram constants with controls and modify the code until all fuzzy wires and fuzzy structures have disappeared.
Try it, it's not that easy. 😉
With N=10000000, x=y=10, the times go from 0.05, 0.05, 0.05 (your code) to the more realistic 0.16, 0.71, 0.94 (code without folding).
Of course you also want to disable debugging (for a result of 0.16, 0.70, 0.81), because you want to measure the math, not the debugging overhead. As you can see, a FOR loop benefits more from disabling debugging than a simple subtract. Seems reasonable.
Happy benchmarking. 😄
Thank you very much for the info! I appreciate the crash course in benchmarking.