10-18-2018 08:25 AM
Thank you everyone for the discussion so far. I am very appreciative of everyone's input.
I have attached a small demo of what my overall code is trying to accomplish. I have an image and I essentially want to add "icons" on the base image. this is a visualization for a simulator.
The inside lo in the picture below matches the case of my original post, since it is called many times and is parallelizable in principal I thought it could be an area of improvement:
10-18-2018 10:41 AM
I think this is fundamentally governed by the issue I described in msg #9. Stating it again, there's a conceptual conflict among:
- data safety and determinism of processing results
- replacing values in-place
- parallelizing the effort which makes the *order* of replacements indeterminate
There's just no way for the compiler to know that doing the operations in an indeterminate order (due to parallelizing) will still yield deterministic results. Although *you* have special knowledge that the run-time values of indices won't have repeats, the compiler can't know that and shouldn't assume it. That's why it won't (and shouldn't) allow For loops with both shift registers and parallelization.
LabVIEW is data-centric and prioritizes the determinism of data operations. Among the consequences are some constraints put on parallelism. It would rather produce the same result every time a little slower than produce varying results a little faster.
-Kevin P
10-18-2018 10:57 AM - edited 10-18-2018 10:58 AM
@Kevin_Price wrote:
There's just no way for the compiler to know that doing the operations in an indeterminate order (due to parallelizing) will still yield deterministic results. Although *you* have special knowledge that the run-time values of indices won't have repeats, the compiler can't know that and shouldn't assume it. That's why it won't (and shouldn't) allow For loops with both shift registers and parallelization.
I agree with this statement 100%, I only really used the for loop / shift register to demonstrate the desired result.I was more or less wondering if there was some other approach that I was overlooking that would allow me to directly access the memory in place given that I do have special knowledge that the run-time values. If I really wanted to parallelize that part of the code I'd probably have to write a .dll or something then, right?
10-18-2018 11:51 AM
Like Altenbach said, you can break up your array into 2, 4, or more parts, and send them to separate loops, roughly equal in terms of how many elements need to be replaced, and then build it back together afterwards.