Re: cvs commit to glibc-package/debian by gotom
At Wed, 18 Sep 2002 09:47:12 -0400,
Ben Collins wrote:
> On Wed, Sep 18, 2002 at 06:38:47AM -0700, Jeff Bailey wrote:
> > On Wed, Sep 18, 2002 at 09:33:51AM -0400, Ben Collins wrote:
> > > And yes, there will be atleast i586/i686/v9/v9b optimized libs when
> > > we release 2.2.xx/2.3.x. The /etc/ld.so.nohwcap patch was meant to
> > > solve the problem I had with this during woody.
It sounds nice. Could you add it into cvs?
> > I don't think I've seen a reply from my email to you on this: At what
> > threshold is this worthwhile? How are you benchmarking this?
>
> For sparcv9, I know the difference first hand (just check the
> debian-sparc archives for what simply going from v7 to v8 does for
> libssl on ultrasparc's). For Sparc, the primary helper is the h/w muldiv
> support we gain by leaving v7. Also means I don't have to kill v7
> support on the entire sparc dist just to give the v8/v9 users some
> speedups.
>
> As for Intel, pretty much the same applies. The speed up from the faster
> h/w math ops help in critical places like libm, ssl, etc.
On intel, the method of pthread compare and swap, memory operation
(memset, etc), and fpu handling as Ben said, etc, are improved.
> I saw before where someone said that simple pentium optimizations gave
> them 3/4% increase. That's good enough for me to justify it.
I also think it's fine.
Evaluating optimization merit with benchmarking is difficult in the
case of glibc: the degree of improvement depends on the rate of
contained optimized functions, so the test-set should be carefully
selected. Unlike gcc (it directly affects all instructions), -opt
package does not affect all applications. However, so many
applications also use the fundamental function like memcpy/fpu of
glibc, so we can get the merit of -opt package.
-- gotom
Reply to: