04-09-2012 03:35 PM
04-10-2012 05:08 PM - edited 04-10-2012 05:09 PM
04-11-2012 08:32 AM
This started as a Resuse Queued Message handler. The external developers wrote a VB program to perfom the actual work then used .net calls to the VB dll. It would have too easy to use the call library function. And oh by the way it is importamt to read back the developers names to Pass the ID test.
There are 8 more states like this! This is going to be a bear to refactor and return it to reuse code.
04-12-2012 03:53 AM
Jeff Bohrer wrote:
Maybe a little simpler...
I guess I'll make the Rube-Goldberg Thread after all!!!
Inspired by Altenbach, I tried a different approach:
No loops!!
Interestingly, it depends on the array type which one is faster. For timestamps it's 50% slower than the above. For floats and integers it is 2x faster.
04-12-2012 09:44 AM
@Anthony de Vries wrote:
Interestingly, it depends on the array type which one is faster. For timestamps it's 50% slower than the above. For floats and integers it is 2x faster.
I typically don't trust these kinds of statements without seeing the benchmarking code. How big were the test arrays?
Just guessing, but the slowness might be due to the fact that we need to allocate a second array of the same size, while the FOR loop does not need to do that. The speed gain for simple numerics might be the utilization of SIMD instructions. Newer LabVIEW versions require an SSE2 capable CPU. It might be instersting to repeat the test after building a benchmark applications for a non-SSE2 system. It might also be due to simple compiler optimizations.
04-12-2012 12:07 PM
@Anthony de Vries wrote:
No loops!!
Interestingly, it depends on the array type which one is faster. For timestamps it's 50% slower than the above. For floats and integers it is 2x faster.
No loops in G != No loops. In the old days loops inside primitives were much faster than in G, that line is blurring now.
Timestamps are of course 128 bit creatures which get coerced to 64 bit DBL. The For Loop method does this one at a time, explicitly. The LV compiler may or may not do this for the array. It could be (depending on LV version) coercing the entire array at once and then subtracting them. If memory is plentiful, no problem.
Once you decide to go down the road of trading memory for speed, I would take Array Subset over Rotate since fewer manipulations are involved. Just subtract the original array from the subset beginning at index 1, and then insert 0 at the beginning.
My LV9 benchmarks (5 million elements):
Timestamps: For Loop (162 msec) < Array Subset (187 msec) < Rotate (201 msec)
DBL: Array Subset (34 msec) < For Loop = Rotate (51 msec)
04-14-2012 07:59 PM - edited 04-14-2012 08:01 PM
Posted in error due to not reading carefully enough.
04-17-2012 09:44 AM - edited 04-17-2012 09:45 AM
How can we ensure that a 3D array is always big enough??
Let's just make it infinite!!!!!
(All we need is 9,903,520,314,283,042,199,192,993,792 bytes of ram. Oh well, that's just a number...)
04-17-2012 01:36 PM
Damn- I only have a 10 Yottabytes of RAM! I'd better go buy a thousand of them!
04-17-2012 02:47 PM - edited 04-17-2012 02:52 PM
79,228,162,514,264,337,593,543,950,336 them's 64bit real floats +4 to store the array size- ( Whoops we actually need all of an I128 to contain size)