NI Home > Community > NI Discussion Forums

BreakPoint

Showing results for 
Search instead for 
Do you mean 
Reply
Knight of NI
altenbach
Posts: 27,601
0 Kudos

Re: Back to Rube Goldberg Code


X. wrote:

Anyone seen this one yet?


Cool!

 

...but a world record with only 300 steps?

I have the nagging feeling that some LabVIEW Rube Goldberg code posted here has more steps than that. :smileyvery-happy:


LabVIEW Champion . Do more with less code and in less time .

Proven Zealot
Jeff·Þ·Bohrer
Posts: 7,989

Jim will love this one

[ Edited ]

Thank you Darin.K


Darin.K wrote:

Jeff Bohrer wrote:

nothing simpler

aa.png

 



Maybe a little simpler...

 

TimeInterval.png


I guess I'll make the Rube-Goldberg Thread after all!!! :smileyvery-happy:

8-Ball Consulting advertising banner

Certified LabVIEW Consultant. The partner you can bank on when you're behind the 8-Ball.
Active Participant
Spectre_Dave
Posts: 312

Use .net to call a VB dll

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.

Macc.JPG

Visualize the Solution

CLA

LabVIEW, LabVIEW FPGA
Member
Anthony_de_Vries
Posts: 188

Re: Jim will love this one


Jeff Bohrer wrote:


Maybe a little simpler...

 

TimeInterval.png


I guess I'll make the Rube-Goldberg Thread after all!!! :smileyvery-happy:



Inspired by Altenbach, I tried a different approach:

DeltaTimes.PNG

 

No loops!!  :smileyhappy:

 

 

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.

Knight of NI
altenbach
Posts: 27,601
0 Kudos

Re: Jim will love this one


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.


LabVIEW Champion . Do more with less code and in less time .

Trusted Enthusiast
Darin.K
Posts: 3,920

Re: Jim will love this one


Anthony de Vries wrote:

No loops!!  :smileyhappy:

 

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)

Trusted Enthusiast
nathand
Posts: 3,878
0 Kudos

Re: Rube Goldberg Code

[ Edited ]

Posted in error due to not reading carefully enough.

Knight of NI
altenbach
Posts: 27,601

Re: Rube Goldberg Code

[ Edited ]

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

 

(seen here)


LabVIEW Champion . Do more with less code and in less time .

Proven Zealot
Jeff·Þ·Bohrer
Posts: 7,989
0 Kudos

Re: Rube Goldberg Code

Damn-  I only have a 10 Yottabytes of RAM! I'd better go buy a thousand of them!

8-Ball Consulting advertising banner

Certified LabVIEW Consultant. The partner you can bank on when you're behind the 8-Ball.
Proven Zealot
Jeff·Þ·Bohrer
Posts: 7,989
0 Kudos

Re: Rube Goldberg Code

[ Edited ]

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)

8-Ball Consulting advertising banner

Certified LabVIEW Consultant. The partner you can bank on when you're behind the 8-Ball.