I think the feature of spreads is very suitable for parallel processing. At that point, vvvv has big potential.
but, I couldn’t find any statement about that. (I apologize if only my searching skill is poor.)
you can do that in a plugin if you want. vux and i did some test years ago, and you wouldn’t see a performance gain unless you went over a spreadcount of 5000 for simple operations. on low spreadcounts the overhead of parallelism was even bigger than the performance gain. but tests are dated by now…
@woei
your experiences is useful for me.
now that you mention that, certainly the overhead does not pay generally.
so, okey… I’ll obediently process on GPU or parallelize by myself when I need performance.
this question means only that I feel a future about parallelism with vvvv. but I got it that is not realistic for now.
good question yhy
Was thinking too about this and how it could look in some cases.
For example reimplementing spreads and slice operations in compute shaders.
Would that result automaticaly in parrallel processing or would the shader calls still happen sequencial? Like with too shader linearspreads next to each other.
On the operation gains, problem is that plugins by themselves also imply some overhead (going from native to managed world and back), so I guess having multi-core operators on native nodes would reduce that threshold by a certain factor.
For reasonably more complex operations gain can be much more significant.
About gpu processing, commands are sent in serial, so you use cores to perform the same tasks, you can’t dispatch several tasks independently.