Darren's Occasional Nugget 08/15/2007

[altenbach]

---

@bienieck wrote:

I did my benchmark (with Your VI) but with enabled debugging so the results are probably not so precise. The problem is that, when debugging is disabled then Your VI works not so well (probably caused by some compiler optimization). Or maybe I'm wrong... 

---

Please be more clear here. What is the meaning of "works not so well"? Is it slower? Are the results incorrect? Typically, compiler optimizations make things faster.

[bienieck]

It made things faster. Execution speed for feedback node equals 0 with optimizations and that is meaning of "works not so well". You can check it by Yourself, maybe it will be different on Your PC.

[altenbach]

What are the units of "0"?

[bienieck]

Miliseconds

For Shift Reg execution was something about 40ms.

[altenbach]

You need to add indicators to the two tunnels in the last frame, else the entire second loop is eliminated as dead code if debugging is disabled.

[bienieck]

I did some more benchmarking of shift registers and feedback nodes with disabled debbuging.

I have interesting results (in my opinion) that is:

If I wire a constant into a count (N) terminal inside Darren's benchmark VI then no matter is it write or read, FN is faster about 20%.

If I wire a control into a count (N) terminal inside Darren's benchmark VI then SR is faster.

Execution speed of read with control wired into N terminal is almost identical for FB and SR but with constan wired into N terminal SR is faster about 10%.

I attached the project with my benchmark if anyone is curious about that. There is also .txt file with results. I hope that i don't mess up.

[Norbert_B]

There are many dependencies on the performance. Watching it for less than a second is.....very unreliable.

That being said, i got about 10-12% performance difference between SR and FN. EDIT: In favor for the FN.

(Loop2Version1)

Replacing the FN with a SR placed the SR on the for loop, making no significant difference to before. EDIT: So the compiler integrates the FN in the for loop instead of creating the overhead of an additional while loop. Otherway round: The compiler does not optimize loop1 to remove the (unnecessary) while loop.

(Loop2Version2)

Removing the while loop in the first loop dropped execution times by more than 33%:

(Loop1Version2)

In this situation, Loop1Version2 was by now 25% faster than Loop2Version2 (images above).

Fiddling out a difference revealed that loop2 uses a tunnel instead of the SR itself to pass the data out of the loop.

Reworking loop2 to match loop1 now:

(Loop2Version3)

Now, loop2 is about 2% slower than loop 1 on my machine reproducably.

All in all, compiler optimizations depend very much on the surrounding of the calling code. In this particular benchmark, loop1 with the while loop does not create the same compiled code as loop2 originally (as the FN connects to the for loop itself instead of inserting an additional while loop).

Norbert