BreakPoint
Rube Goldberg Code
@Tropo wrote:
I didn't get any useful time of that code improvement before I changed it to this:
What is "this"??? You show a blurry picture with hidden wires (four wires hiding under the subtraction, which only has three terminals! 🐵 Makes no sense! We cannot tell how things are connected!
Why does a time need to be "useful"? I don't even know what that means. How does a time look like that's not useful? Isn't it sufficient for the time to be "accurate"?
We are measuring the time per iteration, which is often useful, of example to verify that the loop is not overloaded and can keep up with the desired pace. Are you trying to measure the total amount of elapsed time since the loop started? That could be useful too in some situations, but is a different problem.
@altenbach wrote:
How does a time look like that's not useful?
Time not spend usefully is pretty easy to spot though.
Sure we can come up with fun OT some pictures. But LV related, just look at the code posted on the 203 pages of this thread 
.
Search LabVIEW like a graph! 
( Seen here )
Configuring the trajectory for a scan of a 2D grid apparently needs 4 FOR loops, 3 Shift registers, 2 case structures, and losts of math with code the size of half a page.
Of we could reduce it to the size of a postage stamp.... (even if would would explicitly program the ramps)
Here is often a subconscious notion that in order to fix something, we need to add more code. 😞 Often less is more!
(There is a long thread where more and more structures are added to get a time measurement "just right" (probably still wrong!), finally coming up with this (top of image).
They added:
- 2-frame flat sequence #1
- 2 frame flat sequence #2
- High resolution timer in the FALSE case.
Rearranging things a bit better, we can get away with much less code here (bottom of image). It is also much easier to read!
It is likely that the compiler optimizations will generate almost identical code here, so the benefit is mostly for the programmer.
So would you say these are equivalent in every useful case?
Might save me a few clicks if so 🙂
@cbutcher wrote:
So would you say these are equivalent in every useful case?
Define useful 
.
It's probably exactly the same, except when one starts\wants to wire things to the individual frames.
That FSF is a bit weird, as it's not actually acting as one structure. E.g. wire something to the second frame, and the second frame will wait for that data, while the first frame doesn't wait. Of course the timing in such a use case doesn't make sense at all (e.g. you're doing it wrong). But maybe, just maybe there a useful scenario for it?
@cbutcher wrote:
So would you say these are equivalent in every useful case?
Might save me a few clicks if so 🙂
I never liked bringing outputs out of a FSS frame on the top or bottom.
What happens if "some stuff" contains an asynchronous node and the next developer doesn't realize that and stuffs parallel code outside the structure dependant on the early frames output?
It's just asking for a CLAD or newbie to confuse the bejeezus out of themself and post a topic that would confuse even more people. That failed VIA test should warn you that it's not a super idea. Wire it through exactly as if it was on a SSS local converted to FSS.
Checks for $0.02 may be sent to the address on my Alliance partner page.
Except on a system with a single CPU core, and trying to time an extremely fast function, things will probably be equivalent. You could argue that the additional synchronization boundary between the first two frames in the top code might cause additional rearrangements in the compiled code or even add an additional microscopic delay. Most likely, all this is well below the jitter of typical benchmarks. 😄
So the seemingly easy notion "this does the same thing in useful cases", isn't that easy when looking at it long enough (or with enough people)...
Of course we're making an effort to scrutinize the hell out of such notions .
Always an exception...
Question remains: are those exceptions useful, useless or corner cases? I'd say the latter.
