Optimising execution speed - integer rotation

[rolfk]

---

@altenbach wrote:

On a related note, Google AI seems to confuse me with Rolf 😮

altenbach_0-1785949827664.png

---

Hilarious. Maybe it gets confused by the fact that we both have Swiss heritage. 🙂

[rolfk]

---

@PinguX wrote:

---

@Andrey_Dmitriev  a écrit :.

It seems that LabVIEW doesn't fold for loops 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 ?

PinguX_0-1786009666219.png

I tried with my own implementation :

PinguX_1-1786009797683.png

And the result is that there is a difference between loop and constant, even after compiling as an exe.

PinguX_2-1786009860386.png

---

There might be also an issue about the size of the array. I know for a fact that LabVIEW did some constant folding like that in the past and blew up the VI creating a huge VI file on disk. So there may have been some optimization where the LabVIEW folks decided to not create a constant folded array from a certain size unless it is a real constant.

Of course the perfect optimization would be to have two types of constant folding loops. Up to a certain size constant fold it directly into the VI source code. After that, delegate the generation of the constant folded array to the load time of the VI and keep it in the VI dataspace. But that may require substantial changes in both the compiler and loader.

[Yamaeda]

---

@rolfk wrote:

---

---

Of course the perfect optimization would be to have two types of constant folding loops. Up to a certain size constant fold it directly into the VI source code. After that, delegate the generation of the constant folded array to the load time of the VI and keep it in the VI dataspace. But that may require substantial changes in both the compiler and loader.

---

I had that thought also, maybe it only folds up to 1k data or elements or something like that. I have a strong memory of reading that it does fold e.g. Initialize array in many cases.

[altenbach]

Folding large data structures at compile time will dramatically increase the size of the VI (or the separate compiled code elsewhere) and it is probably better to do it on first run, then fold it for the remainder of the run. Running that loop once in memory is probably faster than loading its output from HD.

[Andrey_Dmitriev]

---

@altenbach wrote:

Folding large data structures at compile time will dramatically increase the size of the VI (or the separate compiled code elsewhere) and it is probably better to do it on first run, then fold it for the remainder of the run. Running that loop once in memory is probably faster than loading its output from HD.

---

To be honest, I'm still not entirely sure how constant folding works in LabVIEW.

In general, compiled code is compressed internally, so to investigate this, I created a very simple pseudo-random generator based on a Galois linear-feedback shift register. According to the visualization, the loop is constant-folded entirely, (but the generated values are not trivial 1, 2, 3, 4, ...; instead, they are pseudo-random, although fully predictable due to the constant seed):

Screenshot 2026-08-21 13.32.57.png

Based on that, I would expect either a huge VI (1 million U64 values ≈ 8 MB) or a significantly larger built application, but that is not the case. The VI remains small regardless of whether the compiled code is stored separately or embedded, and the executable is close to the minimum size, at only about 215 kB. There do not appear to be any precomputed folded constants embedded in it.

Rust, for example, performs such computations at compile time. The generated code can be easily inspected through the assembly output or LLVM IR, but that does not seem to be possible in LabVIEW.