libcaps thread testing code committed

[Joshua Coombs]

Bah, looks like my memory was off.  Ok, back to my hole for me!

Joshua Coombs

"Craig Dooley" <cd5697 at xxxxxxxxxx> wrote in message
news:20031207134601.GA3350 at xxxxxxxxxxxxx
> 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
> ------------------------------------------------------------------
------