Any difference between the "Subtraction" function and Decrement function?

[jamoore84]

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

[MattBradley · Accepted solution]

Well, it would be slower -- but not by too much.

[jon_mcbee]

---

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).

[jcarmody]

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...  

[altenbach]

---

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. 😄

[jon_mcbee]

---

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.