[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CPU specific/optimized Debian builds ?

On Wednesday 29 May 2002 12:16, Andrew Suffield wrote:
> On Wed, May 29, 2002 at 09:48:33AM +0200, Ulrich Eckhardt wrote:
> > On Wednesday 29 May 2002 01:30, Adam Heath wrote:
> > > On Wed, 29 May 2002, Ulrich Eckhardt wrote:
> > > > Debian's debs:
> > > > around 3.6 seconds
> > > >
> > > > compiled bzip2 and tar with DEBIAN_BUILDARCH=k6:
> > > > around 3.5 seconds
> > >
> > > Noise.
> >
> > No. Marginal but visible.

You don't show me yours so I wont show you mine !

> No, it really is noise. At the accuracy you have given (one decimal
> place), a change of 0.1 is statistically meaningless, especially since
> you said "about". It can easily be attributed to aliasing effects (a
> 0.0001 shift about the 3.55 mark will result in a shift from 3.5 to
> 3.6).
You have no idea why I claimed that it is not noise, because you have neither 
seen what I have really done nor have I told you. My short 'no' is also a 
response to your short 'noise', for which you don't tell me your reasons.

However, it really is not noise. That is not a scientific opinion, but one I 
observed, try it yourself and you'll see it. I don't claim that the 
difference is really 0.1 s btw. It may be even smaller, but it was visible 
when switching those two versions. 

> The figures you have given here are not meaningful.
> > > > compiled with DEBIAN_BUILDARCH=k6 and GCCVER=3.0
> > > > around 3.3 seconds
> > > >
> > > > compiled with DEBIAN_BUILDARCH=athlon and GCCVER=3.0
> > > > around 3.3 seconds
> > >
> > > No change for k6/athlon.  However, it appears that GCC=3.0 gives very
> > > good numbers.
> > >
> > > What happens if you compile with just 3.0, but no BUILDARCH?
> > >
> > > Also, use a biggest test case.  This one is rather small.
> >
> > Hmmm, everyone can do so on their own machines easily .... how are the
> > results on yours ? :)
> >
> > I'll give it a more systematic try with a linux-kernel sourcetree instead
> > of my cvsroot, but that's later today.
> That is not a deterministic test. It doesn't provide a particularly
> useful benchmark; it involves a semi-random pattern of disk access
> which is hopelessly skewed by environmental factors.
I picked those two because I use them now and then. I hope that the kernel 
catches all diskaccess so that shouldn't be an issue after the first run. 

Random data has a drawback if I don't use the same set of data for the 
various program to benchmark, therefore some constant but (semi-)random data 
is preferable imho. 

Also the size shouldn't exceed the memory because then it really gets 
IO-bound so small sizes are preferable. A Linux sourcetree is too large, I 
have to admit.

To add some more to this thing, here are some more results. This time I also 
only document the 'user' field of what time reports. System is 
Athlon XP 1700 @ 1470 Hz (256KiB cache, 2929.45 bogomips)
Epox 8KHA+ with 256MiB RAM
Note: these times are only the lowest 'user' result of running 
   tar cjf cvsroot-2002-05-29.tar.bz2 cvsroot
(and cvsroot being 5.3MiB) a few times. Some may claim that I should have 
taken the average, but A) I am too lazy. B) ideally it should always take the 
same time and that time cannot go beneath a certain limit which is the time 
that process really takes, not additional time for context-switches etc ...

All results varied in a range of ~0.1 s, with the occasional escapee.


2.72 s

2.53 s

2.60 s

2.50 s

2.57 s

2.42 s

2.50 s

Two conclusions:
- I'll now recompile some stuff with k6/3.0 :-)
- adding archs to Debian is not really beneficial for my system, the pending 
switch to gcc 3.0 will already do a big step.
- this needs to be reproduced on other systems too. If I want to, I will do 
so on a pentium MMX@300 and a K6-2@500.


To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Reply to: