libcaps thread testing code committed

[Craig Dooley]

I dont think this will work. Anything before the pIII did not have SSE,
so PPro, PII, old Xeons are now useless?  Also, even the pIII only had
SSE, not SSE2, so there is no way to do double precision floating point
with just SSE.  Any Athlon before they went to XP I believe does not
have SSE, and I think there might also be no SSE2 in AMD Chips except
Athlon64 and maybe Barton.  I dont think this many CPU families can be
dropped.  They will have to be supported though.

-Craig

On Sun, Dec 07, 2003 at 08:04:17AM -0500, Joshua Coombs wrote:
> 
> "Matthew Dillon" <dillon at xxxxxxxxxxxxxxxxxxxx> wrote in message
> news:200312070449.hB74nM2B058830 at xxxxxxxxxxxxxxxxxxxxxxx
> >     Thread testing code has been committed for libcaps.  Note that
> the FP
> >     regs are not saved and restored yet (though there is assembly
> to do it
> >     present).  I did some preliminary switch overhead tests with
> fp save and
> >     restore and without.  2 million lwkt_swich() calls execute in
> 0.15
> >     second while the same test which also saves and restore FP
> regs ran
> >     in 0.45 seconds.  So it's the difference between
> 75ns/context-switch
> >     and 225ns/context-switch (on an AMD-64).
> >
> >     So far my investigation into using a delayed-FP-save has been
> >     unsuccessful.  The only way to generate an FP exception on
> FP-use
> >     is with a CR0 bit and needless to say this cannot be done from
> >     userland.  We can designate integer threads to avoid saving
> and
> >     restoring FP regs in those threads, but otherwise I don't see
> any way
> >     to avoid it.... remember, anything that adds a system call
> will add
> >     about a microsecond to the switch code, so implementing
> anything
> >     that requires a system call will wind up being slower then
> just
> >     unconditionally saving and restoring the FP regs.
> 
> As much as I normally champion maintaining support for older
> systems, like 386's, this could be an opportunity to set a minimum
> requirement spec that more matches modern hardware.
> 
> Intel seems determined to move the world away from x87, and afik at
> this point even GCC is capible of targetting all fp code against
> SSE.  SSE support is present in most Athlons and all P3 and up
> cpus... would it be possible to just drop support for x87 fpu and
> move to SSE only?
> 
> Joshua Coombs
> 

-- 
------------------------------------------------------------------------
Craig Dooley                                            craig at xxxxxxxxxx
------------------------------------------------------------------------