[gameprogrammer] Re: Threads and processor affinity
- From: Alan Wolfe <alan.wolfe@xxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Sun, 1 May 2011 22:30:15 -0700
thanks for the responses everyone
i was particularly interested in the case of something like skeletal
animation, doing animation blending as well as possibly CPU skinning.
From the responses it seems the best thing would be just to create as
many worker threads as there are cores, and don't bother with the
affinity stuff and that should work pretty well for most situations.
Thanks again, good info (:
On Sun, May 1, 2011 at 10:17 PM, Charlie Lobo <charlie.lobo@xxxxxxxxx> wrote:
> I'll agree with Brian here: you are not the only program running and have no
> idea what is going on in the rest of the machine.
> I personally believe that you shouldn't care about this unless you are
> having a number of complex, CPU bound threads an order or two of magnitudes
> more than the number of expected CPUs.
> If you do have this situation you should still not try to enforce having
> processes run on a specific CPU or such. Again you have no idea how many
> other threads and processes are running, you are just hoping that your
> program won't have so many threads that the context switching overhead
> becomes huge. Context switching is unavoidable on most OS (exception being
> OS that don't allow parallel proccesing) since even a console has to process
> online conections and other services, and you cannot and most not assume the
> number of threads this take (a single patch could ruin it). Also because you
> can't gaurantee that all threads will be available (disk operations and
> such) you might have idle cores and just waste space. Context switching is
> pretty heavy, but then again so is calling a function (GOSUB) compared to a
> simple GOTO, it's not a problem unless it's abused.
>
> With all this in mind, there are a few solutions:
> A task based system
> A tasklet/cofunction system
>
> In both cases you do create a "task handler" which has a bunch of threads,
> the number being the number of CPU cores as reported by the OS. The system
> recieves "tasks" which are instructions to run a certain function. The
> program then delegates a task to a freed up thread. You'd want the threads
> protected by a semaphore, which allows for multiple resources of which
> anyone could work, request queues, and priotization of the resource
> requests.
> We still have the problem that some tasks would lock up the thread while
> waiting for some resource (network response, disk operation, etc.etc.). It's
> very probable that most threads could lock up for some time in this
> operations causing considerable lag, since you could do other, CPU bound
> operations. So we add the tasks the ability to "terminate" early, this is a
> certain points they go to sleep, until they recieve a signal that the
> non-CPU-bound operation is done, at which point they add themselves back to
> the queue (maybe with a boost in priority) to finish the job. This could be
> implemented with a careful framework using functors, though cofunctions are
> much more powerful for this, depends on what your plataform allows.
>
> So in conclusion:
> Don't care about the number of threads unless you are making a number of
> threads a couple orders of magnitude greater than the CPU cores (aka making
> 200 threads).
> Do you really need to do all this in parallel? Why not just iterate through
> a few of this things in good old fashioned linear programming and reduce the
> number of threads?
> If still you do have to, you are going to rebuild your own context
> switching, which means having to reinvent the wheel, and you are not
> guaranteed to be faster than your OS. Look around, there probably is a
> library that already does that.
>
> On Sun, May 1, 2011 at 12:02 PM, Brian Barrett <brian.ripoff@xxxxxxxxx>
> wrote:
>>
>> A good OS will move processor hungry threads onto idle cores. If it
>> does not, then maybe manually managing the affinity is a solution. A
>> note though: manually managing affinity can be a bad solution, what if
>> all programs did this! They would probably all end up on the first few
>> cores, with any others lying idle. Unless you see evidence of a
>> particular OS mismanaging allocation, I would be hesitant to mess
>> around with affinity.
>>
>> On consoles I imagine it is much more useful, my understanding is that
>> console operating systems are simpler and you aren't competing with
>> other processes for the available cores.
>>
>> On 30 April 2011 18:42, Alan Wolfe <alan.wolfe@xxxxxxxxx> wrote:
>> > Hey Guys,
>> >
>> > I've seen/read in multiple places that people recommend creating at
>> > max one thread per core of the machine to keep the context switching
>> > overhead (and such) from degrading performance.
>> >
>> > I was wondering, when you do that, does it automatically try and put
>> > each thread on it's own core or do you have to force processor
>> > affinity per thread to make that happen?
>> >
>> > I'm most curious about windows PCs but if OS matters, does linux / BSD
>> > behave differently? How about on the 360 or PS3 (excluding the SPUs
>> > hehe)?
>> >
>> > Thanks!
>> >
>>
>> ---------------------
>> To unsubscribe go to http://gameprogrammer.com/mailinglist.html
>>
>>
>
>
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
