in c# there’s System.Threading namespace what makes threading as simple as 1+1. read some references and tutorials on msdn about it.
in vvvv level you can run multiple vvvv’s simultaneously communicating through udp, tcp or sharedmemory
Getting threading working can be easy
But mastering it certainly isnt.
Threading works best when you have more than one significant task which can be run independent of each other for a period of time.
So high spread counts in nodes does make a case for threading. But even better is when you’re performing tasks from multiple nodes in a thread. You can think of this as replacing a section of your patch with a dynamic plugin, and threading that plugin.
my not too deep experience was:
.net backgroundworker and async read/write serves more for not blocking v4, e.g. while processing a huge amount of data. though it feels like the operations need significantly more time then.
Thread.Start as demoed by tf in the samples of plugininterface.v1 is usefull for high spreadcounts as elliot says. experience from vuxens and me was that below 5000 it doesn’t make sense.
and for sift like operations, where you have to do an operation with each slice from one spread with each slice of the other spread. then all the threads take approximately the same time to process and you really gain some performance. an attractor for example works faster threaded (if the input count is higher than the attractor count. each thread would be the operation of one attractor on all input slice, then thread.join and then sum up all the differences).
but probably vux should be commenting in this thread
There’s quite different ways to use threading, roughly:
-Slice based threading (several threads runs part of the operation). That works really well for simple operations with high spread count (or more complex ones like attractor). On low spread count it can be very expensive instead. Finding the “sweet spot” (eg: when threading overcomes non threaded) is quite a pain, depends a lot on your operation/processor. Also i found slice based threading quite very varying time wise (between 2 executions), I prefer sse/avx results are much predictable (you can do both of course, but for a threaded version of something like + (Value) i need a spread count of 100000 for threading to beat sse…
in c# you create several threads to process part of the spread then use Join at the end.
For simple operations (anything without states), if you not scared of using c++ take a look at openmp, just makes c# threading look crap in ease of use/performance.
-Task based threading: you can have something like fluidsolver copying all density data in a thread, velocity in another one, then join. It’s a bit same concept as above, but for 2 operations instead. (openmp equally outshines c# at task parallel operations).
-Background based threading:
for example you could upload a file to ftp server in a thread, then send back progress/success/failure operation as feedback. Very easy to do although have to be careful when input changes on what action you want to take.
Also you could make a complex operation and output result when ready, just have to learn how to do a bit of sync (using locks), single locks are simple, multiple locks can be let’s call it “fun” ;)
-Threaded rendering:
not implemented in directx 9, not a chance ;)
