Dynamic switching of co-processor context
strauman at slac.stanford.edu
Mon Oct 19 18:24:45 UTC 2009
Peter Dufault wrote:
> On Oct 19, 2009, at 10:30 , Till Straumann wrote:
>> This strategy seems reasonable under the assumption that a task
>> who uses the co-processor once is likely to use it in the future again.
>> For tasks that 'always' use the co-processor it eliminates the need
>> for handling an exception every time the task is given the CPU.
> My problem with this is that a bug either in the compiler (generates
> floating point when it seems as if it shouldn't, something we're all
> familiar with),
usually, these are not compiler bugs but the result of optimization and very
likely to happen more often with every new gcc release.
E.g., when you tell gcc that your CPU has a vector unit (altivec, sse)
then it will use
this for all kinds of things.
> build flags, or in the task will let the thread just silently start
> incurring the additional context switch overhead from then on when you
> didn't expect it. You could add a soft "And this thread is allowed to
> use the co-processor" flag to address that.
At the end of the day I'm not sure the entire effort is worth it, just
gcc implicitly will use co-processors if you tell it your CPU has them.
Due to ABI incompatibilities it is not a good idea to compile different
units with and w/o co-processor support.
I'm not sure the added overhead on a fast CPU is *that* significant
(and low-end CPUs tend to lack fancy co-processors). Especially
if the code is a tuned to be cache-friendly.
You might just 'bite the bullet' and always switch full context.
AFAIK, since we have made 'all tasks FP tasks' for PPCs with a hard
FPU there have been no complaints (or even observations) that performance
has suffered. And that has been several years ago IIRC.
More information about the users