Wouldn't that be rather 360 specific? In the regular .net framework you can set affinity and priority on a thread, isn't that sufficient? Or does the XNA framework introduce a new way of dealing with threads?
Does the lock and volatile keyword work the same on the 360?
Thanks,
Roger Larsen
twospoons wrote: Wouldn't that be rather 360 specific? In the regular .net framework you can set affinity and priority on a thread, isn't that sufficient?
But that doesn't target a specific core, which would be useful.
explicit model: you tell the OS which core each thread should run on,
and then the OS keeps out the way and leaves you to it. Wheras on
Windows the OS is far more sophisticated (and heavyweight) doing all
sorts of automatic allocation behind the scenes even if you don't
specify an explicit affinity.
We figured that since the underlying OS concepts are quite different,
and anyone writing multithreaded code probably cares enough about
performance that these differences are going to be important for them,
it didn't really make sense to try to make affinity look the same on
the both platforms. It will be similar, but even tiny differences can
be important for that sort of code!
Jim Perry wrote:
twospoons wrote:
Wouldn't that be rather 360 specific? In the regular .net framework you can set affinity and priority on a thread, isn't that sufficient? But that doesn't target a specific core, which would be useful.
You can still do this with ProcessThread. Just set the ProcessorAffinity for each thread and you are good to go.
Roger
Shawn Hargreaves wrote:
Xbox threading is somewhat different to on Windows. It is a much more explicit model: you tell the OS which core each thread should run on, and then the OS keeps out the way and leaves you to it. Wheras on Windows the OS is far more sophisticated (and heavyweight) doing all sorts of automatic allocation behind the scenes even if you don't specify an explicit affinity. We figured that since the underlying OS concepts are quite different, and anyone writing multithreaded code probably cares enough about performance that these differences are going to be important for them, it didn't really make sense to try to make affinity look the same on the both platforms. It will be similar, but even tiny differences can be important for that sort of code!
So basically you need different code blocks for different platforms. Does the kernel still schedule the threads, or is it more of a fiber approach? I'm more worried about volatile and locks, if they behave diffrently then we will have issues.
Roger Larsen
twospoons wrote:
Jim Perry wrote:
twospoons wrote:
Wouldn't that be rather 360 specific? In the regular .net framework you can set affinity and priority on a thread, isn't that sufficient? But that doesn't target a specific core, which would be useful.
You can still do this with ProcessThread. Just set the ProcessorAffinity for each thread and you are good to go.
I misunderstood, my bad.
Undoubtedly, though, there's some OS differences that require tweaking of the threading model.
twospoons wrote:
So
basically you need different code blocks for different platforms. Does
the kernel still schedule the threads, or is it more of a fiber
approach? I'm more worried about volatile and locks, if they behave
diffrently then we will have issues.
The Xbox kernel schedules threads preemptively, but I'm pretty sure it
won't reallocate them from one core to another. You often won't need to
care about the differences from Windows: it is only when writing super
optimized parallised game engines that these subtleties can become
important.
Volatile and locks will follow the standard CLR behavior.
Does all the cores share the same L2 cache (Core 2 Duo style)? Does the hardware threads on each core share the same L2 cache?
Sorry for all the questions, but if you have some docs to point me to I'll read those instead :)
Thanks,
Roger Larsen
twospoons wrote:
Does all the cores share the same L2 cache (Core 2 Duo style)? Does the hardware threads on each core share the same L2 cache?
Sorry for all the questions, but if you have some docs to point me to I'll read those instead :)
There is a single shared L2 cache. Each of the three cores has its own
L1 cache, which is shared between the two hardware threads on that core.
http://www-128.ibm.com/developerworks/power/library/pa-fpfxbox/ has
some more details. Ars Technica also did a gory low level article on
the 360 CPU, but it seems to be subscribers only.
WOW "Instructions were added to calculate the dot-product of two vectors made from three or four floating point values" "The CPU chip can use code running in one of the cores to "procedurally generate" the equivalent triangles to represent the object. The data representing these triangles will reside in the L2 since the L1 is store-through. The GPU can read modified data directly from the L2 cache without causing a castout or change in cache state." Wonder how much of this insane power we can tap into :) Roger Larsen |