LabVIEW
Fun benchmark: modify last column in an 2D array (I almost guessed wrong)
Solved!
I made a quick array modification SubVI to modify the last column.
Secondly, why not optimize this code slightly? And what is optimization without a benchmark?
Task, multiply last column with 1.000001. Do this 1 000 000 times.
Method 1: use array functions. Method 2: use in place array functions
So in my head "Method 2" should be the best one in most if not all input examples.
What "Method 1" 25 times quicker?
Hmmm, I remind myself again I need to stop doing this small optimizing tasks 😄
Optimizing before finding something that actually matters to optimize, is not the way to go if you want to get more done.
So, then at last, what is optimizing without turning off debugging?
Wow, in-place method won!!!!!!! 😅
@Yamaeda wrote:
What about a 3rd method? Just Index out the last last column, mulitply and Replace Array?
Ok, had to add it to the test, Method 3. Slightly modified to compare similar code.
With debugging on this Method 3 is the winner.
But turning debugging off, Method 2 still wins:
Thanks 🙂
Hi paljacob,
@paljacob wrote:
With debugging on this Method 3 is the winner.
But turning debugging off, Method 2 still wins
Please read/watch the tutorials/presentations given by Christian Altenbach on "good benchmarking"!
This whole test is flawed:
- don't use locals to forward large datasets
- right now you also benchmark the time needed to read the data from the locals and the time needed to store the result in an indicator
Try to time only each "core" loop!
What's the point of manipulating the same array column a million times when you only keep the result of the last iteration? Seems a quite senseless operation!
All you do is testing LabVIEWs ability to index/edit array elements spread across a large memory block: arrays are stored row-wise in memory…
I'd use an IPE structure like this:
EDIT: Oops probably need to switch dimension to 1...
Search LabVIEW like a graph! I never used IPE with split array before, so thanks for sharing!
I guess for many of these methods, the very small data set is not fair to the method, but it shows how different it can be.
So with debugging on:
And debugging off:
Crazy how Method 4 costs like 400 times more than method 2.
@paljacob wrote:
I never used IPE with split array before, so thanks for sharing!
I guess for many of these methods, the very small data set is not fair to the method, but it shows how different it can be.
So with debugging on:
And debugging off:
Crazy how Method 4 costs like 400 times more than method 2.
As mentioned, your benchmark is not valid.
I get 40 ms on my method, 1.5 us if I put the locals outside the structure.
I get:
And:
OOPS: Probably messed that up... Anyway, with the locals in the loop, you won't get fair results.
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.
GerdW: All methods are performing the same task right? Do you agree? Anyway, I just had to test it 🙂
FYI: doing the same task 1 000 000 times is just to get a more measurable benchmark on a function like this.
So to challenge your statements I modified the benchmark to run methods 1 to 4 without reading and writing to inside the benchmark, but also added a copy where locals are used and writing to the indicator is included. First, as this read/write is only done once during the benchmark, it does not matter too much. Secondly, it shows that it does not change the ranking between the methods (but debugging on/off changes ranking).
Debugging on:
Debugging off:
Picture of the benchmark code:
