Rube Goldberg Code

[altenbach]

---

@billko wrote:

You know, this is mainly a fun thread, but we could use it as an excellent tool to post what we think is Rube-ish code and see if anyone can help us un-Rube it.

---

This thread has 1740+ posts, so real code help should probably go elswhere, one problem/thread. We are un-rubeing code daily here, but it is a sysiphean task! 😄

[thoult]

---

@altenbach wrote:

Of course all output terminals should have self-explanatory names. Most seem to be at the defaults.

---

This would also fail our internal coding standards for the number of terminals used, as it's likely to be unsuitable for a 4-2-2-4 connector pane with no room for expansion.

[JÞB]

---

@Ray.R wrote:

Ran into this code today and it seems to be screeming Rube Goldberg.  Any comments?

 

---

I'd likely increment the array of indicies after the loop as opposed to incrementing each index in the loop but, benchmark that first.  Drop-in-the-ocean difference in performance for %99.99..... of use cases but forming a good habbit for the really oddball use case.  Inlined- there should be no differance (I Think!)

[Yamaeda]

I don't really see how this function could be simplified, apart from putting the Increment outside i can't see any leaner way to build a list of active channels.

Assuming 50% reduction of array size, you'll save 50% Increments, which is noticable if the array is very (very) large. 🙂

/Y

[altenbach]

What bugs me more is that the channel counting is 1 based instead of zero based. Must be a matlab programmer. 😄

If the boolean array is gigantic (here it definitely isn't) and the TRUEs are very sparse, one could possily try something with "search array" in a while loop. It probably still won't be faster. One way or another, it needs to inspect each element.

[James_W]

Any performance enhancement from moving the Increment outside and +1 to all array elements after creation?

[altenbach]

---

@James_W wrote:

Any performance enhancement from moving the Increment outside and +1 to all array elements after creation?

---

Probably not if most elements are retained. As Yamaeda already said, having it outside is faster with the elapsed time proportional to the number of elements retained by the conditional tunnel. If the output array is empty, it is fastest. 😄

( If most elements are retained and if it were DBL, there may or may not be a small difference due to the possible use of SIMD if the increment is outside. This is such a fast loop on a small array that it would not be noticeable.).

[JÞB]

---

@James_W wrote:

Any performance enhancement from moving the Increment outside and +1 to all array elements after creation?

---

As I said. %99.99.....Not enough to notice.  Go ahead and work up a benchmark;)  In really hardcore computational needs (with debugging disabled) You might find a way to improve the compiler (On some Si)

Frankly, I should not even be posting this.  Its way over my head.

0

[Ray.R]

Sometimes the obvious escape us.  Thanks Jeff...  

Like you said, it's a good practice.  🙂

The code I was looking at the time is now busied in noise... In an ocean of code pieces begging to be debugged, re-written or trashed.  There are tidbits being refactored..  If I run across that piece of code, I will check it out.  I am quite sure the array is quite small.  

[JÞB]

@JÞB wrote:

@Ray.R wrote:

Ran into this code today and it seems to be screeming Rube Goldberg.  Any comments?

 

I'd likely increment the array of indicies after the loop as opposed to incrementing each index in the loop but, benchmark that first.  Drop-in-the-ocean difference in performance for %99.99..... of use cases but forming a good habbit for the really oddball use case.  Inlined- there should be no differance (I Think!)

---

@altenbach wrote:

---

@James_W wrote:

Any performance enhancement from moving the Increment outside and +1 to all array elements after creation?

---

Probably not if most elements are retained. As Yamaeda already said, having it outside is faster with the elapsed time proportional to the number of elements retained by the conditional tunnel. If the output array is empty, it is fastest. 😄

( If most elements are retained and if it were DBL, there may or may not be a small difference due to the possible use of SIMD if the increment is outside. This is such a fast loop on a small array that it would not be noticeable.).

---

Here is where I will most likely get myself into trouble (with a chance of learning something today)

I did say a benchmark would help but, there is no really good way to benchmark that specific code.  I've been triing to find out if there is any operation that takes place on the value of data that will not be retained.  Essentially, going way back to my youth, I learned it is pointless to operate on the value of a data point just before dumping the data itself out of memory.  The bit-bucket just doesn't care what the values are!  It treats all bits and bytes the same without bias.  Way back when it was the programmers job to look at the programming sheet and modify it so those moot value manipulations never made it to the punchcard deck (it saved stresses on the vacuum tubes.)

That's about the last time I needed to get quite so deep into optomizing an instruction set.  Brighter minds than mine have found ways to save me from writing that kind of R-G construct!  And, there are several points between the BD and machine instruction where moot data value manipulations could theoretially be injected.  I theory (as I know it) the LabVIEW compiler could optomize that code, the RTE could recognize the pattern, a pre-processor could intercept the moot instructions and I think an OS could be taught to laugh off "Busy-work" that will never be stored or presented to a user.  That being said, if the optomization is known to exist at a lower level there is no need to duplicate it at a higher one.  Or, is there? - it would depend on the return in performance for each specific implementation I THINK.

I Warned you that I would get myself into trouble here and am in over my head