LabVIEW
Interpolate Pixel
A few minor tweaks and cleanups.
But why is LV showing me hash marks on non-constant wires, and not showing them on constant wires?
@Andrey_Dmitriev wrote:
In this particular case don't think that this will improve much, moreover, you will be surprised — SGL in my test (2023 and 2024 64-bit) is roughly twice slower:
That's quite surprising to me, but thanks for testing it.
@Yamaeda wrote:
@Andrey_Dmitriev wrote:
In this particular case don't think that this will improve much, moreover, you will be surprised — SGL in my test (2023 and 2024 64-bit) is roughly twice slower:
That's quite surprising to me, but thanks for testing it.
The parallel execution might not help at all here.
If the SubVI isn't a clone, parallel execution just overhead.
If it is a clone, the SubVI will calculate the LUT for each instance. That is probably a higher cost that the gain of parallel execution.
If the LUT as in a class's private data that wouldn't be a problem 🤗.
Search LabVIEW like a graph! 
wiebe@CARYA wrote:
@Yamaeda wrote:
@Andrey_Dmitriev wrote:
In this particular case don't think that this will improve much, moreover, you will be surprised — SGL in my test (2023 and 2024 64-bit) is roughly twice slower:
That's quite surprising to me, but thanks for testing it.
The parallel execution might not help at all here.
If the SubVI isn't a clone, parallel execution just overhead.
🤗.
You're right, thanks to point on this.
But in this case parallel execution will help, but more for doubles and less for singles, which is also interesting.
No parallel execution, singles slightly ahead of doubles:
4 Threads parallel execution, now penalties on singles:
16 threads parallel execution, faster, same proportion:
The NaN is a constant, so it won't adapt to the wired type.
Not sure if that's the mistake (it seems irrelevant compared to all other math), but a mistake nonetheless.
It will convert the input to dbl to do compare, and that will be slower for a sgl than a dbl.
