koobas.hobune.stream
Threading in Unity is "...virtual" ?! :D
Hello guys!
I am using about 100 threads in Editor, when they are calculating different tasks on the click of a button for about a minute or so
There is not interaction with Unity API, but if there are more than 100 threads, unity's main thread tends to freeze. When I open resource manager, it shows that CPU currently is 100% used by Unity, and the RAM used is 330 MB.
But it also shows that it is using 20 threads at maximum! (and is only 1 process)
Does that mean I am really not using threading, but just letting the processor to alternate between them quickly?
If so, what is the way to do threading?
for each of my threads, I am saying :
Thread t1 = new Thread(new ParameterizedThreadStart(Function1));
t1.Start(object FunctionArgument);
Thank you for help :)
What you're doing is a bad idea if you don't run on serious multicore hardware. As the switching burns cpu too.
Also a lot of the synchronizing code you may be using, uses the default ThreadPool, like if you use Timers or BackgroundWorker or asynchronous delegates etc. And that pool is limited in Size.
You should shrink down your number of threads and queue your work, you don't get more throughput by increasing thread counts anyway.
You could also search for some altenate Threadpool implementations. There are some nice ones out there.
Thank you Happy$$anonymous$$oo!
What would you say is the most optimal count for i7, i5? or core 2duo?
So should I split the task to say, 4 quarters, using like 20 threads complete q1, when it's done, use new 20 threads for quarter2, etc?
Also, how come task manager is saying that unity runs on 20 threads, although its unity threads + $$anonymous$$y threads? (should be more :s)
The max 20 threads look like you are using the default Threadpool somewhere, so every time you wait somewhere for something to continue, you are waiting for something to execute on the default thread pool, so everything sleeps till it gets a run at the default Threadpool to synchronize your normal threads. But one would need to look into this in more detail to know for sure.
If you want to do a Threadpool approach, you enque WorkItems of some kind and if a thread is done with a WorkItem, it puts the result somewhere and checks if there's another WorkItem in the Queue waiting.
Have all Threads do all WorkItems. Only have special Threads, if you know that the normal Queue can get very long with long waiting times and you need to make sure some special jobs have priority and get executed on their own threads even if the main queue is clogged.
Don't use more than 2 threads per core if you can help it.
20 Threads sounds like way overkill and you only split work items in quarters if you need intermediate results... like lets say you want to do this:
Work to do:
1. Some fast calculations that decide if we need to do step 2
2. Some heavy calculations that can take $$anonymous$$utes - maybe getting URLs from the web etc..
Now... if you would do both steps in the same work item... what you would see is some work items taking 1/2 second and some taking $$anonymous$$utes... and that's ok if you don't need to know how many of which type you have at all times.
But maybe you want to know as fast as possible what kind of work item it is - if it's gonna finish fast or take long.
Now what you could do is have workItems for step1 and workItems for step2... so every work item will stop after step1 and tell the system if it needs to do step2 or not... so you always have a current count of how many step2 jobs will be in the queue, without having to wait for the step2 to finish and without ti$$anonymous$$g your jobs and deciding that if it runs longer than a second, it's probably a long job or some kind of hacks like that. So all jobs that need a second step, get enqueued in a step2 work item.
