LabVIEW
Fun benchmark: modify last column in an 2D array (I almost guessed wrong)
Solved!
@paljacob wrote:
First, thank you for your feedback!
wiebe@CARYA: Ok, I must be blind or something. I can't see what you see 🙂
Could you share your .vi? I don't understand how you managed to get your results.
As mentioned in the last line of that post, I messed up those benchmarks.
I didn't wire the output indicator, getting much better results that you'd get.
Search LabVIEW like a graph! It puzzles me that the IPES performs so badly.
This is supposed to make things faster, but apparently the compiler can make the pragmatic code faster than the 'efficient code'...
Just for fun, replace the X with a compound arithmetic. I go from 65ms so a whapping 1.2 s. 20 times slower!
It's questionable if these benchmarks are fair, or realistic.
With a small modification, the results change dramatically:
Weirdness all over the place...
@paljacob wrote:
Compound arithmetic, wow! I guess I should be careful with compound arithmetic on 2D-array multiplication (assuming that is its weak spot).
I totally agree that there is something fishy going on here. But finding which is the most efficient method on such a dataset I think is valid. I guess we could run this benchmark e.g. 100 times and see at the time distribution on each method to see how it generally performs.
Both the tunneling as the shift register are valid use cases. Which is more realistic depends 100% on how you'll use the routine.
A valid benchmark would test it in the real life situation. Putting the code in a sub VI will make a difference as well. Reentrancy and inlining will make a difference as well, but also not always as expected. In some situations, inlining can slow down things dramatically, which is totally unexpected. I'll leave an example to others, that probably have it ready to post...
@paljacob wrote:
Compound arithmetic, wow! I guess I should be careful with compound arithmetic on 2D-array multiplication (assuming that is its weak spot).
IIRC, the compound arithmetic is compiled to a function call. The multiply function on the other hand is compiled to an assembler instruction. The function call requires a lot more boiler plate code, and is slower. I might be wrong, it's been a while since I looked into it.
If this is true, it's slower for scalars as well. If the overhead of the call is really what causes the slowdown, and not a data copy, the speed difference might actually be even scarier for scalars...
wiebe@CARYA wrote:
It's questionable if these benchmarks are fair, or realistic.
With a small modification, the results change dramatically:
Weirdness all over the place...
What happens to the IPE if you get rid of the "Mark as Modifier" option? (I am talking about the little pencil on the IPE structure, I think that is name.) I was told never to use that, it was only for certain OOP operations.
mcduff
PS Until recently the IPE was not always really in-place. Normal arithmetic operations like your multiply would cause a data copy. Newer versions have eliminated that problem. See this link
@mcduff wrote:
wiebe@CARYA wrote:
It's questionable if these benchmarks are fair, or realistic.
With a small modification, the results change dramatically:
Weirdness all over the place...
What happens to the IPE if you get rid of the "Mark as Modifier" option? (I am talking about the little pencil on the IPE structure, I think that is name.) I was told never to use that, it was only for certain OOP operations.
It doesn't seem to make a difference. It tells the compiler that the data is modified, in case that's not clear. In this case, it is clear. So the compiler marks it as modifier anyway. You shouldn't set it, because it usually doesn't do any good (the compiler will know if it's needed), and can be bad (if you don't modify the data but it is marked).
A use case for it is when the data is modified in a dll. The compiler won't (always?) know the dll modifies the data. The code will work, but the data isn't marked as "spoiled". So when running the code twice, the first time the data is initialized, the second time the data is reused, as it's not spoiled.
I'll have this on my list for my (unconfirmed) presentation at the upcoming global CLA (aka GLA), about OpenCV...
New insight from AQ!
https://forums.ni.com/t5/LabVIEW/LabVIEW-2015-Buffer-Allocation-Bug/m-p/3304776#M967151
This explains a few things!
The workaround however is still 2X slower that the slowest, and 80X slower than the winner...
