LabVIEW
Optimising execution speed - integer rotation
Solved!
@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. 🙂
@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. 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.
@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.
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.
@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.
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):
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.
@Andrey_Dmitriev wrote:
@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.
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):
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.
If we assume/test if there's a 1k elements limit to folding, how is the size affected if you generate 10, 100, 500 and 1000 elements instead?
@Andrey_Dmitriev wrote:
In general, compiled code is compressed internally, so to investigate this,
Having a tight loop with simple code and deterministic outcome is the most optimal way of "data compression" and it will be cheap to "uncompress" during loading from disk. Maybe that is happening here. Wildly guessing, of course. 😄
@altenbach wrote:
@Andrey_Dmitriev wrote:
In general, compiled code is compressed internally, so to investigate this,Having a tight loop with simple code and deterministic outcome is the most optimal way of "data compression" and it will be cheap to "uncompress" during loading from disk. Maybe that is happening here. Wildly guessing, of course. 😄
I think I understand it now. This is not real “constant folding” in the sense of performing the computation at compile time and replacing the result with a constant, as happens with trivial arithmetic expressions. Instead, it’s a form of lazy memoization — essentially caching: an invariant result is computed once at run time on first use, stored in memory, and then reused again and again. I was simply confused by “Rust‑like” constant evaluation and expected that LabVIEW would be smart enough to execute and evaluate the for‑loop at compile time, but it doesn’t.
It’s easy to demonstrate this — just measure the execution time for the first iteration and for each subsequent one.
