wrote: wrote: Try wrapping code in a single-iteration FOR loop. I think that will guide the compiler to multi-thread.
An In-place Element Structure might do the same thing. The goal here is to make sure the "clumping" is separate.
I just tested it with the in-place element structure (replacing the For loops in the second example) and it doesn't work, the execution time just stacks. I tried using both normal tunnels for the array in/out as well as the "in place in/out element" terminals - same result. In contrast, a single-iteration For loop (like in the second example but with normal tunnels instead of auto-indexing and with N = 1) successfully forces multi-threading. I also tried replacing the For loops with While loops (with true wired to the abort terminals) and it does multi-threading only if the in/out array goes through shift registers but not through simple tunnels 
...
The question is what are predictable criteria for clumps to actually use different threads? It's definitely not memory size or execution time. In my first example above, each exponential primitive takes about 50ms for a 1 million element array, but the behavior is the same even for 100 million elements where execution takes several seconds and a gigabyte or so of memory. What exactly forces multi-threading and is it reliable or does it depend on magical circumstances of the compiler?