> I can't see anything in the kernel source code to explain it. Since
> you don't mention actual times, is the difference statistically
> significant? (see src/tools/tools/ministat)
Ministat says: Difference at 95.0% confidence
The second set are always smaller than the first set no matter how
On Thu, 2005-Dec-15 17:59:38 +, Pete French wrote:
>Got some curiuous results when I tested this today by the way.
>I have a twin processor PIII machine. Did a parallel compile on
>it. The actuall wall clock time is faster when I add the 586
>back in. *but* if you look at the user and system ti
> UTSL: The i586 optimised routines were only ever enabled if the CPU
> was identified as a 586. And these routines have been disabled since
> mid-2001. See my mail in the "Odd performance problems..." thread
> for more details.
Got some curiuous results when I tested this today by the way.
I h
On Thu, 2005-Dec-15 12:53:59 -, Steven Hartland wrote:
>Same here be nice to get a catagoric answer to this.
>
> Steve
>- Original Message -
>From: "Randy Rowe" <[EMAIL PROTECTED]>
>>
>>I have multiple dual and quad Pentium Pro machines running 4.x that have
>>been
>>remarkably stabl
Same here be nice to get a catagoric answer to this.
Steve
- Original Message -
From: "Randy Rowe" <[EMAIL PROTECTED]>
I have multiple dual and quad Pentium Pro machines running 4.x that have
been
remarkably stable using the I686_CPU setting (kudos to the developers!!).
So I add mys
Jonathan Noack wrote:
> Kevin Oberman wrote:
>
>> Scott Long wrote:
>>
>>> Also, taking out CPU_I586 is usually a bad idea. It offers no
>>> performance penalties (unlike CPU_I386 and maybe CPU_I486), but
>>> enables things like optimized bcopy.
>>
>>
>> Ahh, This is the sort of thing I never rea
> Is a minor update to the handbook needed in order avoid confusion then?
> e.g. I have been commenting out CPU_I586 on all my PIII systems in the
> (mistaken it would seem) belief that having CPU_I686 only was better.
I've been doing the same thing myself - removing the CPU_I586 on PIII and
new
On Thu, Dec 15, 2005 at 12:17:21AM -0500, Mike Jakubik wrote:
> Mark Kirkwood wrote:
> >Is a minor update to the handbook needed in order avoid confusion
> >then? e.g. I have been commenting out CPU_I586 on all my PIII systems
> >in the (mistaken it would seem) belief that having CPU_I686 only wa
On Wednesday 14 December 2005 10:55 pm, Scott Long wrote:
> Jonathan Noack wrote:
> > Kevin Oberman wrote:
> >> Scott Long wrote:
> >>> Also, taking out CPU_I586 is usually a bad idea. It offers no
> >>> performance penalties (unlike CPU_I386 and maybe CPU_I486), but
> >>> enables things like opti
Mike Jakubik wrote:
Mark Kirkwood wrote:
Is a minor update to the handbook needed in order avoid confusion
then? e.g. I have been commenting out CPU_I586 on all my PIII systems
in the (mistaken it would seem) belief that having CPU_I686 only was
better.
Agreed, i have always just used I686,
Mark Kirkwood wrote:
Is a minor update to the handbook needed in order avoid confusion
then? e.g. I have been commenting out CPU_I586 on all my PIII systems
in the (mistaken it would seem) belief that having CPU_I686 only was
better.
Agreed, i have always just used I686, assuming it inherited
Scott Long wrote:
Jonathan Noack wrote:
Kevin Oberman wrote:
Scott Long wrote:
Also, taking out CPU_I586 is usually a bad idea. It offers no
performance penalties (unlike CPU_I386 and maybe CPU_I486), but
enables things like optimized bcopy.
Ahh, This is the sort of thing I never real
Scott Long wrote:
Jonathan Noack wrote:
Kevin Oberman wrote:
Scott Long wrote:
Also, taking out CPU_I586 is usually a bad idea. It offers no
performance penalties (unlike CPU_I386 and maybe CPU_I486), but
enables things like optimized bcopy.
Ahh, This is the sort of thing I never realized
Jonathan Noack wrote:
Kevin Oberman wrote:
Scott Long wrote:
Also, taking out CPU_I586 is usually a bad idea. It offers no
performance penalties (unlike CPU_I386 and maybe CPU_I486), but
enables things like optimized bcopy.
Ahh, This is the sort of thing I never realized. Is there anythi
Kevin Oberman wrote:
Scott Long wrote:
Also, taking out CPU_I586 is usually a bad idea. It offers no
performance penalties (unlike CPU_I386 and maybe CPU_I486), but
enables things like optimized bcopy.
Ahh, This is the sort of thing I never realized. Is there anything in
the handbook that co
15 matches
Mail list logo
