LabVIEW
Optimising execution speed - integer rotation
Solved!
Understood. Gerd's was not attached, so I did not bother testing. Your mod was to precompute some constants.
Yes, Worrying about performance would be important when processing gigantic datasets. Here's it is more about the fun of coding alternatives. The original "green" code is probably still easiest to understand in the absence of diagram comments, even though it is >10x slower.
Some might still remember the official bit-twiddling challenge from decades ago, but the page has disappeared. 😄
On a related note, Google AI seems to confuse me with Rolf 😮
@altenbach wrote:
Understood. Gerd's was not attached, so I did not bother testing. Your mod was to precompute some constants.
Yes, Worrying about performance would be important when processing gigantic datasets. Here's it is more about the fun of coding alternatives. The original "green" code is probably still easiest to understand in the absence of diagram comments, even though it is >10x slower.
Some might still remember the official bit-twiddling challenge from decades ago, but the page has disappeared. 😄
On a related note, Google AI seems to confuse me with Rolf 😮
Now I feel a bit strange standing between two Knights… especially after Google’s AI confidently informed us that you’re actually the same person
Yes, I remember this bit-twiddling code challenge, but I didn’t participate. In general, I don’t compete in performance challenges where the code is restricted to LabVIEW only, because for me it makes no sense. If I see real bottlenecks in pure LabVIEW code, I simply switch to a DLL — that’s it. This doesn’t mean that LabVIEW performance is unimportant; I usually write LabVIEW code as efficiently as I can.
Back to competitions: my last one on NI was the Median code challenge — you might remember it as well (and I think you were the winner). In that contest we had to find the median of a million floating‑point numbers. I wrote a simple DLL using a trivial trick: if we interpret IEEE‑754 32‑bit floats as integers at bits level, the corresponding integer values increase monotonically with the float values. So we can switch from floats to integers, and in C this is just a pointer cast, but in LabVIEW such a conversion requires copying the entire array. Then I used a histogram‑based method: first I computed a 64K histogram of the most significant 16 bits, found the median bucket, then took the less significant 16 bits of the corresponding values and performed another histogram search. As a result, I needed only two passes over the input array and two passes over the histograms — no sorting at all. The DLL‑based solution was about 10× faster than LabVIEW. But of course that was a rules violation — and the LabVIEW version was an absolute nightmare. I shared that spaghetti with you, and I still remember your “wow”...
Ah, no, actually, I did participate in one more challenge — Summer of LabVIEW 2024. The first one was the Word Search Challenge. I read the rules twice — there were no limitations about DLLs. I grabbed the first suitable open‑source implementation from GitHub, wrapped it in a DLL, compiled with CVI and immediately landed in first place within one evening. But then the organizers (Derrick Bommarito) contacted me and kindly asked to remove my solution because DLLs were not allowed. Rewriting everything in LabVIEW was extremely hard, but I still managed to reach second place — mostly thanks to good utilization of the AMD Ryzen CPU used for that challenge, with plenty of parallel for‑loops. Greg McKaskle beat me at the last minute, though:
In the next challenge, Wordle, I had my revenge — I finished first, but with a bit of “cheating”: I used the digits in results score as feedback about the words and iteratively optimized the decision tree again and again using known strings (I sent around 200 submissions):
One good thing nowadays is that we don’t need to type much code. In that topic, I just took the requirements from the first message, sent them to Copilot as‑is, and got working code immediately in both Rust and C. The only minor issue was that the output array was reversed, but that was fixed with an additional prompt. Rewiring LabVIEW code took me more time than simply copy‑pasting C code and compiling it with CVI and then GCC (and the command‑line string for the compiler was also kindly provided by Copilot). So a reasonable combination of DLLs and LabVIEW can not only improve performance but also save overall development time — although sometimes it may introduce a few exceptions or crashes. The only important point is that the amount of text‑based code must be moderate and splitted into short functions; otherwise you need too many tokens, and beyond a certain size LLMs start hallucinating and the code becomes unmaintainable. But in general I really love modern technologies, both hardware and software — they are fantastic.
Soory for kind of offtopic.
Hi,
@altenbach wrote:
Gerd's was not attached, so I did not bother testing.
I didn't attach the code because it's so easy to recreate. (I didn't even save the VI.)
And I also had no code to begin with, so I typed some example data in the input array.
@altenbach wrote:
Your mod was to precompute some constants.
I left the small loop to create the bitmask values because the compiler should be smart enough to replace it by "constant folded" pre-compute data.
@GerdW wrote:
I left the small loop to create the bitmask values because the compiler should be smart enough to replace it by "constant folded" pre-compute data.
Oh, don't trust the optimizer too much, Gerd, don't trust. You're being way too optimistic.
Some compilers can do that, but not LabVIEW:
Even a trivial case won't work:
for loops with a predictable constant output into a constant. Rust does.
@Andrey_Dmitriev a écrit :.It seems that LabVIEW doesn't foldforloops with a predictable constant output into a constant. Rust does.
That is quite interesting. I really believed what I understood from NI's "compiler under-the-hood" documentation. But it seems that I was wrong. Either I didn't quite understand, or it was just wrong ?
I tried with my own implementation :
And the result is that there is a difference between loop and constant, even after compiling as an exe.
@PinguX wrote:
@Andrey_Dmitriev a écrit :.It seems that LabVIEW doesn't foldforloops with a predictable constant output into a constant. Rust does.That is quite interesting. I really believed what I understood from NI's "compiler under-the-hood" documentation.
You're absolutely perfectly right. The constant folding was just affected by the surrounding Sequence Structure. Feel the difference:
Yes, this loop with a constant output is folded, or at least it appears as folded on the block diagram. I was slightly wrong with my earlier ultimate statement about all for-loops. Sorry about that.
