Multithreading

very high on my wishlist for vvvv is the support of multithreading (without the need of “external tricks” as described on catweasels userpage)

I am currently working on a patch that is heavily using the pipet node on a very fast Core 2 Quad Extreme QX6800 (4x2933MHz).
Everything is working good and also performance is very good - BUT - looking at the TaskManager you have to realize that three of the four cores are doing almost nothing and only one core is doing all the work.

Is there any chance for support of multithreading in the near future ? (perhaps only for CPU-hungry nodes like pipet as a first step - do not know if this makes sense and is possible)

Markus

yes please vvvv developers, this is really needed

there is a big problem: all nodes must be calculated in a frame and without the result of the nodes connected to an input of another node, you cant’t claculate anything. so parallel calculation of a patch graph is not possible. you can’t calc the nodes connected to the output of pipet while the pipet code is running and has no result yet.

as you can see, its very hard to make vvvv multithreaded as it functions now. one had to analyze the graph before to find things, that can be calculated in the same time, sort them an make a thread out of each. this is hardcore computer science and would take a lot of time (that nobody has (nobody pays)).

BUT, it’s clear, that computer power in future will come from parallelism and not from frequency and that the devvvvs are in the need to react.

the idea of multithreading the calculation of single nodes looks best to me for a start…

i think tonfilm made a very good point.

note also that a good portion of the ease of use of vvvv stems from the concept, that all calculations are conceptually done at the same time, the output of a node is there in the same frame as the input is there. to keep this property, a lot of synchronisation needs to be done.

digital circuits dont have this property, which makes designing complex circuitry really different. A similar mess happens right now already with the multithreaded directshow based nodes, or the HTTP nodes, which dont wait for the HTTP server to finish.

on the other hand: what do you want to archieve with pipet? perhaps you just need an optimized code path from a renderer to, say, a dmx interface?