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.
BUILDARCH/BUILDGCCVER
i386/2.95
2.72 s
i386/3.0
2.53 s
i486/2.95
2.60 s
i486/3.0
2.50 s
k6/2.95
2.57 s
k6/3.0
2.42 s
athlon/3.0
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.
uli
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: