John R Pierce wrote:
however, something like mprime/prime95 is a special case. as each CPU
has its own cache, and mprime/prime95 is heavily optimized for cache
usage, having it flip between processors will require a lot of extra
cache reloading, as well as requiring constant floating point state
save/reloads
I'm pretty sure most x86 multiprocessor systems are smart enough to
postpone saving/restoring the FPU state until a process actually tries
to use it... since most processes don't do ANY FPU or only occasionally
a little, this means if a CPU is sharing between prime and non-FP job,
the floating point state doesn't need to be saved/restored at all, as
the FPU state is quite large, this saves a LOT of cycles..
I'm not aware, that any of the current x86 CPUs is able to postpone a FSAVE/FXSAVE.
There are several reasons:
- the CPUs do have some hardware support for task switching, but this doesn't include
on-core caching of the task state segment yet and also doesn't save the FP registers
(because of that most OSes doen't use this feature)
- saving and restoring the FPU state is negligible compared to the amount of required
reloading of cache lines used by the previous thread, which have been thrown out of
the cache etc. and there are still the other data handled by the scheduler during
this task switch.
It would be simpler to give Prime95 more CPU time per scheduled run. 10 times more
CPU time would eliminate 9 of 10 (if I'm counting correctly ;)) task switches
including FPU state saving/restoring.
If the CPU designers are going for speeding up this process, then they'll very likely
go for the complete task switch and add some capability to keep such things in the
data or even some special caches.
Matthias
_______________________________________________
Prime mailing list
[email protected]
http://hogranch.com/mailman/listinfo/prime
