[gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Philippe Lafoucrière]

here is an article comparing debian / mandrake / gentoo speed :

http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[brett holcomb]

Well, if speed is all they want to worry about <G>. 
 However, I find that one of the biggest advantages of 
Gentoo is no more RPMs!!!!  Come to think of it - if I 
factor in all the time it takes to get all the 
dependencies and files to satisfy them on an RPM based 
system then Gentoo is way faster - by days <G>.

On 13 Aug 2003 15:38:21 +0200
  Philippe Lafoucrière <lafou@wanadoo.fr> wrote:
>here is an article comparing debian / mandrake / gentoo 
>speed :
>
>http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1
>
>
>
>--
>gentoo-dev@gentoo.org mailing list
>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Sven Vermeulen]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

On Wed, Aug 13, 2003 at 10:07:54AM -0400, brett holcomb wrote:
> Well, if speed is all they want to worry about <G>. 
> However, I find that one of the biggest advantages of 
> Gentoo is no more RPMs!!!!  Come to think of it - if I 
> factor in all the time it takes to get all the 
> dependencies and files to satisfy them on an RPM based 
> system then Gentoo is way faster - by days <G>.

RPMs are no bad invention. The only problem is that the RPM-based
distributions lacked a decent frontend for a long time. Most users where also
informed that "rpm -i" was the preferred method to install software.

Think of RPM vs Ebuild. How many times do you install an ebuild using "ebuild
<ebuildfile> merge"?

Wkr,
	Sven Vermeulen

-- 
    Save some animals, eat a vegetarian.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Alan]

[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]

On Wed, Aug 13, 2003 at 05:03:19PM +0200, Sven Vermeulen wrote:
> On Wed, Aug 13, 2003 at 10:07:54AM -0400, brett holcomb wrote:
> > Well, if speed is all they want to worry about <G>. 
> > However, I find that one of the biggest advantages of 
> > Gentoo is no more RPMs!!!!  Come to think of it - if I 
> > factor in all the time it takes to get all the 
> > dependencies and files to satisfy them on an RPM based 
> > system then Gentoo is way faster - by days <G>.
> 
> RPMs are no bad invention. The only problem is that the RPM-based
> distributions lacked a decent frontend for a long time. Most users where also
> informed that "rpm -i" was the preferred method to install software.
> 
> Think of RPM vs Ebuild. How many times do you install an ebuild using "ebuild
> <ebuildfile> merge"?

True.  Mandrake's urpmi seems to work nicely though, once you get a good
mirror.  My thing for liking portage over others though is not getting
rid of rpms or extra speed but the transparancy of the system, the
protage SLOT system and good old USE flags.  If
mandrake/debian/redhat/etc provided distros that  had choices  gnome/kde,kde 
and no gnome, no kde and gnome, all graphics formats, no gif, all png, no
snmp, all snmp, etc, then they would get my attention.  Preaching to the
choir here I know but the flexability of USE flags and the ability to
not only compile what I want, but do it with the options I want, is
huge.  The slashdot doubters do have a point though, as the last time I
upgraded KDE in gentoo it was a day or more of compiling, opposed to an
hour or so (if that) of downloading debs/rpms and 5 minutes of
installing them :)  That's the compromise though I guess :)


-- 
Alan <alan@ufies.org> - http://arcterex.net
--------------------------------------------------------------------
"There are only 3 real sports: bull-fighting, car racing and mountain 
climbing. All the others are mere games."                -- Hemingway

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 558 bytes --]

On Wed, 2003-08-13 at 12:15, Alan wrote:
> huge.  The slashdot doubters do have a point though, as the last time I
> upgraded KDE in gentoo it was a day or more of compiling, opposed to an
> hour or so (if that) of downloading debs/rpms and 5 minutes of
> installing them :)  That's the compromise though I guess :)

You could always install only the GRP packages and only upgrade them
that way.  In fact, even the GRP packages are more optimized than the
ones given out by the other distributions.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1314 bytes --]

On Wed, 2003-08-13 at 09:38, Philippe Lafoucrière wrote:
> here is an article comparing debian / mandrake / gentoo speed :
> 
> http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1

Proper testing would have yielded different results.  Also, there is no
way to duplicate the results since there is zero information on the
setup.  In any scientific circle, this data would IMMEDIATELY be thrown
out since it cannot be reproduced.  They also had no "control" group. 
It would also have been nice to have seen them test Gentoo (optimized)
against Gentoo (non-optimized).  Testing should have also been done on
the SAME machine.  Not "identical" machines, but the exact same one. 
The reason for this is there is the possibility that hardware could be
causing a discrepancy in the results.

The "Gentoo Approach" also is not limited to simply optimization, but
also to the customization and control over your system that a Gentoo
user gets.

I have found that most Gentoo converts don't even bother to use much
optimization, but rather enjoy the ease of use and control much more.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Brad Laue]

Chris Gianelloni wrote:
>   They also had no "control" group.
> It would also have been nice to have seen them test Gentoo (optimized)
> against Gentoo (non-optimized).  Testing should have also been done on
> the SAME machine.  Not "identical" machines, but the exact same one. 
> The reason for this is there is the possibility that hardware could be
> causing a discrepancy in the results.


This is the main thing that bugs me - the programs tested were built 
with no more opimizations than any other distribution uses (-O2 is 
extremely common).

Another good analysis of the 'gentoo approach' would have been trends 
based - if I set gnome in my USE flags, how will the featureset of my 
entire system change over time? Can such features be added and removed 
on the fly in other distributions? (probably not)

Brad


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Philippe Lafoucrière]

> Proper testing would have yielded different results.  Also, there is no
> way to duplicate the results since there is zero information on the
> setup.  In any scientific circle, this data would IMMEDIATELY be thrown
> out since it cannot be reproduced.  They also had no "control" group. 
> It would also have been nice to have seen them test Gentoo (optimized)
> against Gentoo (non-optimized).  Testing should have also been done on
> the SAME machine.  Not "identical" machines, but the exact same one. 
> The reason for this is there is the possibility that hardware could be
> causing a discrepancy in the results.
> 
> The "Gentoo Approach" also is not limited to simply optimization, but
> also to the customization and control over your system that a Gentoo
> user gets.
> 
> I have found that most Gentoo converts don't even bother to use much
> optimization, but rather enjoy the ease of use and control much more.

totally agree ! Btw, gnumeric speed is related to version apparently,
and they didn't use the official gentoo (patched) kernel ("The same
2.4.21 source was copied to all machines"). This sux !!

I don't use gentoo for optimization, but ease of use and management :)
I've tried to install a red hat 9. It's pretty fast for a i386 distro !
More faster to start openoffice for exemple. But redhat network updates
killed my nerves ! 

Gentoo roxor :)


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Philippe Lafoucrière]

On Wed, 2003-08-13 at 16:20, Philippe Lafoucrière wrote:
> > Proper testing would have yielded different results.  Also, there is no
> > way to duplicate the results since there is zero information on the
> > setup.  In any scientific circle, this data would IMMEDIATELY be thrown
> > out since it cannot be reproduced.  They also had no "control" group. 
> > It would also have been nice to have seen them test Gentoo (optimized)
> > against Gentoo (non-optimized).  Testing should have also been done on
> > the SAME machine.  Not "identical" machines, but the exact same one. 
> > The reason for this is there is the possibility that hardware could be
> > causing a discrepancy in the results.
> > 
> > The "Gentoo Approach" also is not limited to simply optimization, but
> > also to the customization and control over your system that a Gentoo
> > user gets.
> > 
> > I have found that most Gentoo converts don't even bother to use much
> > optimization, but rather enjoy the ease of use and control much more.

btw, it seems that they didn't use prelink with gentoo, when it's used by default on mdk :(



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

On Wed, 2003-08-13 at 10:20, Philippe Lafoucrière wrote:
> totally agree ! Btw, gnumeric speed is related to version apparently,
> and they didn't use the official gentoo (patched) kernel ("The same
> 2.4.21 source was copied to all machines"). This sux !!

The Gentoo kernel would have made a big difference.  Also, gnumeric is
plainly a dog.  They also did not take into account that Mandrake uses
prelink on all of its binaries by default.  This decreases load times
significantly and makes for a "snappier" system.

> I don't use gentoo for optimization, but ease of use and management :)
> I've tried to install a red hat 9. It's pretty fast for a i386 distro !
> More faster to start openoffice for exemple. But redhat network updates
> killed my nerves ! 

Once again, the OpenOffice thing is a result of prelink.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Alan]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

On Wed, Aug 13, 2003 at 10:32:52AM -0400, Chris Gianelloni wrote:
[snip]
> The Gentoo kernel would have made a big difference.  Also, gnumeric is
> plainly a dog.  They also did not take into account that Mandrake uses
> prelink on all of its binaries by default.  This decreases load times
> significantly and makes for a "snappier" system.
[snip]
> 
> Once again, the OpenOffice thing is a result of prelink.

Maybe prelink should be used all the time on gentoo?  Make it part of
the "default" so that it's always there and able to make things even
faster.

-- 
Alan <alan@ufies.org> - http://arcterex.net
--------------------------------------------------------------------
"There are only 3 real sports: bull-fighting, car racing and mountain 
climbing. All the others are mere games."                -- Hemingway

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Patrick Kursawe]

[-- Attachment #1: Type: text/plain, Size: 393 bytes --]

On Wed, Aug 13, 2003 at 09:17:18AM -0700, Alan wrote:

> Maybe prelink should be used all the time on gentoo?  Make it part of
> the "default" so that it's always there and able to make things even
> faster.

Presence of the "prelink" program is not enough. You also have
to run it, which takes quite some time. I would not like to have
it automatically run after each emerge...

Bye, Patrick

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Wed, 2003-08-13 at 12:22, Patrick Kursawe wrote:
> Presence of the "prelink" program is not enough. You also have
> to run it, which takes quite some time. I would not like to have
> it automatically run after each emerge...

The idea was to add it to FEATURES.  Also, it would only prelink the
specific package that you just installed, so it would not take quite so
long.  I still see tons of problems with that, especially in the form of
prelinking libraries.  A newer version of a library would not only
require itself to be prelinked, but also any application which referred
to that library.  This is a slippery slope and is easily dealt with in
binary distributions, but quite a bit harder to accomplish on a
source-based distribution.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 701 bytes --]

On Wed, 2003-08-13 at 12:17, Alan wrote:
> Maybe prelink should be used all the time on gentoo?  Make it part of
> the "default" so that it's always there and able to make things even
> faster.

I have some serious doubts about the stability of prelink.  I have
recently had 2 separate systems get hosed by using prelink.  Luckily, I
had one system which had not been prelinked and everything has distcc,
so I was able to "repair" my system by using the working machine.  One
of my friends has had the same issue, so it is not limited to me and my
setups.  I am trying to track down the problem's origin so I can file a
decent bug report.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 975 bytes --]

On Wednesday 13 August 2003 22:32, Chris Gianelloni wrote:
> On Wed, 2003-08-13 at 12:17, Alan wrote:
> > Maybe prelink should be used all the time on gentoo?  Make it part of
> > the "default" so that it's always there and able to make things even
> > faster.
>
> I have some serious doubts about the stability of prelink.  I have
> recently had 2 separate systems get hosed by using prelink.  Luckily, I
> had one system which had not been prelinked and everything has distcc,
> so I was able to "repair" my system by using the working machine.  One
> of my friends has had the same issue, so it is not limited to me and my
> setups.  I am trying to track down the problem's origin so I can file a
> decent bug report.

I tried out prelink myself too, and stopped using it precisely for this 
reason. It does not appear to be stable for me either.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[FRLinux]

On Wed, 2003-08-13 at 15:20, Philippe Lafoucrière wrote:
> totally agree ! Btw, gnumeric speed is related to version apparently,
> and they didn't use the official gentoo (patched) kernel ("The same
> 2.4.21 source was copied to all machines"). This sux !!

Well i don't think this sucks, keeping at least consistency on the
kernel between the 3 distributions is a good idea. Now, that being said,
they seriously fsck'd up the rest of the test and optimisations.

I don't use specific gentoo kernels on my boxes, this is a personal
choice made about a year ago and actually since 2.6, i don't use 2.4
anymore on personal machines (my laptop and my workstation).

Steph
-- 
Mail sent on Gentoo 1.4rc3 k2.6-test3 AMD 2600+
http://frlinux.net - frlinux@frlinux.net
http://gentoofr.org - Portail Francais sur Gentoo Linux




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[William Kenworthy]

I posted this to the gentoo-user list by mistake last night (it was
after midnight and ...) - wondered why I didnt get too many
flames/replies!

Apologies to those who get two copies, but it was originally meant to go
with this thread to stop the mis-information:

______posted to gentoo-user_______________________

I'll stick my hand up and say I was the person who installed gentoo for
this test.  For those who made the previous posts (mostly crap, and who
dont seem to have read the article very well - though it could have been
more informative), perhaps a few facts may help:

1. was fully bootstrapped and compiled as stage 1/2/3 on the machine -
not a binary install
2. gentoo-sources 2.4.20 was used - Mandrake came with a newer kernel
than gentoo's reccomended one (still does), debian was a dogs breakfast
because stable is so old.  We actually tried to put the gentoo kernel on
mandrake/debian when tracking down the ide cable prob, but got too hard
- not the way some posts tried to imply)
3. optimisations were EXACTLY as recommended by both the make.conf
entries, which were supported by the cflags from the forum for this cpu:
a 2G celery (P4 based core)  I am not sure now, but I believe I ran
prelink as well (to match mandrake) - need to find and check the notes.
4. Gnumerics problems have been identified and come down to the
particular version - is fixed in the upcoming stable release even before
this was found, but the project was unaware that what they believed was
a slightly slower mod in this version, could be so bad on particular
data sets - i.e., 30 odd mins in 1.0.13, but is less that 30s on 1.0.19
on my laptop

There seems to be quite a few myths about this test and people upset
that months were not spent tuning gentoo and every effort made to
cripple the competition! (one person even suggested the faulty ide cable
should have been left in the debian box, as that was the way it was
delivered!)  Read the article, and if you need extra information to
reproduce it, email me or or the author (Indy).  It is reproducable - if
you can obtain the same hardware - I would be very interested if someone
has this and the time to really go into the why these results occurred
in more detail than I had the chance to.

and why was this the result?  Daniel Robbins suggested on this list that
gentoo-sources may be the problem, but tests on another machine (we had
the trial machines for only a couple of days, all of which time was used
to build gentoo right up until I ctrl-c'd the OO build so we could do
the tests before handing the hardware back) showed that turning off
pre-empt and low-latency had zero effect, but changing to an open-mosix
kernel 2.4.20  was ~10% slower (no thread export).  It seemed to come
down to the fact we used -O3 instead of -O2 (think spider might have
suggested this ?)- in effect over-optimised, and we didnt have a chance
to correct. From my perspective, most of the "he should have used ...
may actually have made performance even worse! And besides the time
issue, these were supposedly the safe, reccomended flags so we went with
them.  Please note that even Mandrake made only a slight gain on debian,
so 386.586/686 does not make a lot of difference in real world tasks
(the original aim of the tests) - the tests did tasks that particular
people used linux for in their day-to-day work - no special tests, so no
special bias.  Yes, I could choose tests that make gentoo shine, or
debian, or windowsXP.  But I dont do those tests every day, whilst that
spreadsheet was/is used as part of my normal work.  And its the same
with the other tests.

So how many gentoo systems out there have every possible optimisation in
the book, and are actually running slower than ideal?  This is a real
problem, and I will be interested in how the cflags projects around
handle this, as most seem to aim at setting the maximum possible flags:
not actually tune the system for the ones that work best/most stably.  A
live benchmark test might be more appropriate.

Most posts on irc and lists have settled down to "he doesnt know what
he's doing" (I do), or the tests were unfair to gentoo (they werent, but
then the same criteria were met by all 3 systems, but with some question
marks over debian because of its mix - some packages had to be compiled
locally, not binary) - but the thrust of the article was not that gentoo
was a dud, but that this was the result within the criteria and time we
were given, not what we expected, so we need to find out why.  Also note
that this was not intentionally a debian/mandrake/gentto distro test.

We may be getting a P4 hyperthreaded system to play with, but under
different rules, where I get to do a bit of tuning first.  I have
already built the core system on another machine using gcc-3.2.3,
"-march=pentium4 -O3 -pipe -fomit-frame-pointer"  I note that the
pentium4 warning still appears in make.conf, though I believe it no
longer applies to this gcc.

A while ago I emailed this list and asked for information on tests and
settings for HT P4's, without a reply.  So again, has anyone done any
tests on a HT P4 and is willing to support the flags they chose as being
"the best"?  In particular, does -ffast-math give a measurable gain? 
Most of my machines have been built as scientific stations, so accuracy
is more important than ultimate speed, so this is one I have never
tested.  I am not interested in the -O9 -max-everything kiddies who have
been so vocal, but reasoned choices.

If you want to flame, go ahead - but support your statements!

:)

BillK



On Thu, 2003-08-14 at 05:15, FRLinux wrote:
> On Wed, 2003-08-13 at 15:20, Philippe Lafoucrière wrote:
> > totally agree ! Btw, gnumeric speed is related to version apparently,
> > and they didn't use the official gentoo (patched) kernel ("The same
> > 2.4.21 source was copied to all machines"). This sux !!
> 
> Well i don't think this sucks, keeping at least consistency on the
> kernel between the 3 distributions is a good idea. Now, that being said,
> they seriously fsck'd up the rest of the test and optimisations.
> 
> I don't use specific gentoo kernels on my boxes, this is a personal
> choice made about a year ago and actually since 2.6, i don't use 2.4
> anymore on personal machines (my laptop and my workstation).
> 
> Steph
-- 
William Kenworthy <billk@iinet.net.au>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Brian Jackson]

The only thing I had wrong with the article was that different machines were 
used. Which was even mentioned when the author was discussing the problems 
with the IDE cable. At work I've bought computers in batches before and seen 
very wide variances amongst components that you would think would be close 
(due to them being from the same lots). I don't if the next tests you (and 
the author) are planning will take place on the same box, but I would try to 
if I were you ( I know it takes a long time, but it adds credibility). As far 
as the CFLAGS for a P4, I can't help you there. I'm all AMD's and Via C3's :)

--Brian Jackson

On Wednesday 13 August 2003 05:49 pm, William Kenworthy wrote:
> I posted this to the gentoo-user list by mistake last night (it was
> after midnight and ...) - wondered why I didnt get too many
> flames/replies!
>
> Apologies to those who get two copies, but it was originally meant to go
> with this thread to stop the mis-information:
>
> ______posted to gentoo-user_______________________
>
> I'll stick my hand up and say I was the person who installed gentoo for
> this test.  For those who made the previous posts (mostly crap, and who
> dont seem to have read the article very well - though it could have been
> more informative), perhaps a few facts may help:
<snip>

-- 
OpenGFS -- http://opengfs.sourceforge.net
Home -- http://www.brianandsara.net


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Paul de Vrieze]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 1605 bytes --]

> We may be getting a P4 hyperthreaded system to play with, but under
> different rules, where I get to do a bit of tuning first.  I have
> already built the core system on another machine using gcc-3.2.3,
> "-march=pentium4 -O3 -pipe -fomit-frame-pointer"  I note that the
> pentium4 warning still appears in make.conf, though I believe it no
> longer applies to this gcc.
>
> A while ago I emailed this list and asked for information on tests and
> settings for HT P4's, without a reply.  So again, has anyone done any
> tests on a HT P4 and is willing to support the flags they chose as being
> "the best"?  In particular, does -ffast-math give a measurable gain?
> Most of my machines have been built as scientific stations, so accuracy
> is more important than ultimate speed, so this is one I have never
> tested.  I am not interested in the -O9 -max-everything kiddies who have
> been so vocal, but reasoned choices.
>
> If you want to flame, go ahead - but support your statements!

Well all packages that cannot handle -march=pentium4 should filter it out. 
This filtering is imprefect so adding -mcpu=pentium4 should ensure correct 
scheduling of all packages. One thing, do not use -ffast-math, as can be seen 
in the manual this can actually produce mathematic errors. Normally one does 
not want this in most packages, so leave it alone. It could be used in things 
like games, wher the precision does not matter that much, but it is not safe 
as a default.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 10898 bytes --]

On Wed, 2003-08-13 at 18:49, William Kenworthy wrote:
> I'll stick my hand up and say I was the person who installed gentoo for
> this test.  For those who made the previous posts (mostly crap, and who
> dont seem to have read the article very well - though it could have been
> more informative), perhaps a few facts may help:
> 
> 1. was fully bootstrapped and compiled as stage 1/2/3 on the machine -
> not a binary install

Great.  I read the article and found no mention of the USE flags
employed.  I think you should have honestly posted any information on
things you changed.

> 2. gentoo-sources 2.4.20 was used - Mandrake came with a newer kernel
> than gentoo's reccomended one (still does), debian was a dogs breakfast
> because stable is so old.  We actually tried to put the gentoo kernel on
> mandrake/debian when tracking down the ide cable prob, but got too hard
> - not the way some posts tried to imply)

Were preemption and low latency turned on?  Was the kernel compiled with
the >gcc31 selection for the CPU?  Better yet, why not post the .config
from the 3 kernels?
 
> 3. optimisations were EXACTLY as recommended by both the make.conf
> entries, which were supported by the cflags from the forum for this cpu:
> a 2G celery (P4 based core)  I am not sure now, but I believe I ran
> prelink as well (to match mandrake) - need to find and check the notes.
> 4. Gnumerics problems have been identified and come down to the
> particular version - is fixed in the upcoming stable release even before
> this was found, but the project was unaware that what they believed was
> a slightly slower mod in this version, could be so bad on particular
> data sets - i.e., 30 odd mins in 1.0.13, but is less that 30s on 1.0.19
> on my laptop

I hope you only used optimizations listed in the forums for the actual
version of GCC you're running.  From the sounds of it, you did not since
you used pentium3 and the pentium4 problems were fixed in the most
recent stable GCC.  You also should have definitely used a "default"
Gentoo install with no changes made.  The default profile setup would
have been used instead.  Your optimizations could have been researched
from GCC rather than taking the word of a bunch of "armchair compiler
experts" on the forums.  No offense meant to anyone, but you mention
below that you do much scientific work, yet followed a very poor
scientific model and research documentation for this article, which is
why it has been torn apart so adamantly.  Had you given out all of the
information, even if it were simply links to the files from within the
article, it would have given your article much more credibility.

> There seems to be quite a few myths about this test and people upset
> that months were not spent tuning gentoo and every effort made to
> cripple the competition! (one person even suggested the faulty ide cable
> should have been left in the debian box, as that was the way it was
> delivered!)  Read the article, and if you need extra information to
> reproduce it, email me or or the author (Indy).  It is reproducable - if
> you can obtain the same hardware - I would be very interested if someone
> has this and the time to really go into the why these results occurred
> in more detail than I had the chance to.

The same machine should have been used for the testing, rather than
three machines.  This alone is reason enough to discount your data. 
Three different machines WILL have three different levels of
performance.

> and why was this the result?  Daniel Robbins suggested on this list that
> gentoo-sources may be the problem, but tests on another machine (we had
> the trial machines for only a couple of days, all of which time was used
> to build gentoo right up until I ctrl-c'd the OO build so we could do
> the tests before handing the hardware back) showed that turning off
> pre-empt and low-latency had zero effect, but changing to an open-mosix
> kernel 2.4.20  was ~10% slower (no thread export).  It seemed to come

I agree with Daniel on some of this.  The default Gentoo kernel is not
the fastest out there, it is the most feature rich to meet the various
needs of our user base.  I do agree that this kernel should have been
used rather than any other.  Also, preempt and the low-latency are
interactivity increases, not raw performance increases.  Their
modifications are not easily quantifiable.  If you want to test them, I
suggest you look into ConTest
(http://members.optusnet.com.au/ckolivas/kernel/) which was designed for
testing this sort of thing.

> down to the fact we used -O3 instead of -O2 (think spider might have
> suggested this ?)- in effect over-optimised, and we didnt have a chance
> to correct. From my perspective, most of the "he should have used ...

No, you definitely "should have used" -O2 rather than -O3.  Also,
-fomit-frame-pointer and -mfpmath=sse would have given dramitic
improvements.  I'm not going to go into any other optimizations because
the rest are essentially very specific to the hardware/software being
used.  I think these are the only "sensible" extra defaults that can be
used on a machine with SSE.

> may actually have made performance even worse! And besides the time
> issue, these were supposedly the safe, reccomended flags so we went with
> them.  Please note that even Mandrake made only a slight gain on debian,
> so 386.586/686 does not make a lot of difference in real world tasks
> (the original aim of the tests) - the tests did tasks that particular

386, 586, 686 make little difference compared to 386, 586, pentium4,
which is how it should have been.

> people used linux for in their day-to-day work - no special tests, so no
> special bias.  Yes, I could choose tests that make gentoo shine, or
> debian, or windowsXP.  But I dont do those tests every day, whilst that
> spreadsheet was/is used as part of my normal work.  And its the same
> with the other tests.

I actually agreed with most of your tests.  You had a hard time being
very time constrained.  Honestly, were I in your position, I would not
have made this report at all unless I had a MUCH longer time to test
things.  You should look into the kinds of testing that many of the
hardware sites out there use.  They tend to take WEEKS on a single
article.  It doesn't take their full attention that entire time.  After
all, there's only so much interaction you need to do when running a
script which performs hundreds of actions and logs results to a file.

> So how many gentoo systems out there have every possible optimisation in
> the book, and are actually running slower than ideal?  This is a real

I use quite a few optimizations, which I benchmarked on my machine with
my application/data set and it is the fastest I was able to come up
with.  I have actually turned OFF quite a few of the optimizations
recommended by many of the "airmchair compiler experts" out there
because they either provided little to no improvement or actually
decreased performance.  I really don't care if something is 0.001%
faster if it takes 400% as long to compile.  Especially being a
developer and compiling quite a bit of stuff several times over.

> problem, and I will be interested in how the cflags projects around
> handle this, as most seem to aim at setting the maximum possible flags:
> not actually tune the system for the ones that work best/most stably.  A
> live benchmark test might be more appropriate.

I agree 100% here.

> Most posts on irc and lists have settled down to "he doesnt know what
> he's doing" (I do), or the tests were unfair to gentoo (they werent, but
> then the same criteria were met by all 3 systems, but with some question
> marks over debian because of its mix - some packages had to be compiled
> locally, not binary) - but the thrust of the article was not that gentoo
> was a dud, but that this was the result within the criteria and time we
> were given, not what we expected, so we need to find out why.  Also note
> that this was not intentionally a debian/mandrake/gentto distro test.

Not being able to tune Gentoo essentially means you did not participate
in the "Gentoo Approach" but rather kludged it together fairly untuned
and pitted against a tuned binary installation and debian.

> We may be getting a P4 hyperthreaded system to play with, but under
> different rules, where I get to do a bit of tuning first.  I have
> already built the core system on another machine using gcc-3.2.3,
> "-march=pentium4 -O3 -pipe -fomit-frame-pointer"  I note that the
> pentium4 warning still appears in make.conf, though I believe it no
> longer applies to this gcc.

It does not apply to the newest stable GCC, so you are correct.

> A while ago I emailed this list and asked for information on tests and
> settings for HT P4's, without a reply.  So again, has anyone done any
> tests on a HT P4 and is willing to support the flags they chose as being
> "the best"?  In particular, does -ffast-math give a measurable gain? 

There is not much in the way of HT as it is looked at as a SMP machine
under Linux.  All you really do is enable SMP and make sure you use ACPI
in the kernel.  The default Gentoo kernel does not have many of the HT
scheduling changes which have gone into the making of the 2.6_test
kernels.  There are backports for these, but I would consider that going
a bit overboard, as hand-patching your kernel sources would yield better
results on all three systems and should be left alone.  After all,
you're wanting to test the results of the three systems, not of your
hand-made kernel.  If you were to decide to use another kernel, I would
say to use the latest vanilla kernel and possibly the latest 2.6_test
kernel on each distribution using the exact same .config to see how much
the kernel makes a difference in performance.  You should not use
-ffast-math in anything as a default, as it causes math errors which
should not be introduced into a stable system.

> Most of my machines have been built as scientific stations, so accuracy
> is more important than ultimate speed, so this is one I have never
> tested.  I am not interested in the -O9 -max-everything kiddies who have
> been so vocal, but reasoned choices.

The -O9 kiddies are the "armchair compiler experts" I spoke of earlier. 
They have zero real knowledge of compilers and optimizations at all, but
have "heard from a friend" or "read on a forum" about it so they think
they know it all.  I will gladly admit that I know little about
compilers, but I have taken the time to do actual benchmarks on my
system to test my various theories and have chosen what I feel to be the
best combinations for my own needs.

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[William Kenworthy]

A good reply - answer point by point

On Thu, 2003-08-14 at 20:30, Chris Gianelloni wrote:
> On Wed, 2003-08-13 at 18:49, William Kenworthy wrote:

> Great.  I read the article and found no mention of the USE flags
> employed.  I think you should have honestly posted any information on
> things you changed.
> 
No longer available, but I dont think its relevant to the tests we did.
Interesting for some maybe, but not a performance issue.
This was originally set up as a simple test of 3 relatively new to the
distro users installing for the first time.  i.e., if I moved from RH to
gentoo, where would I start: read through make.conf which is where the
docs say to go and set the system up that way and so on.  Again, both
time and this approach means extensive tuning, and changes that are not
part of the initial install were not done.  USE flags are to turn
options in packages off and on, not set up performance (well at least
directly), so I just used the minimum to get the install working for the
tests.  Superficially, this should be faster as it wouldn't install too
much extra

> > 2. gentoo-sources 2.4.20 was used - Mandrake came with a newer kernel
> > than gentoo's reccomended one (still does), debian was a dogs breakfast
> > because stable is so old.  We actually tried to put the gentoo kernel on
> > mandrake/debian when tracking down the ide cable prob, but got too hard
> > - not the way some posts tried to imply)
> 
> Were preemption and low latency turned on?  Was the kernel compiled with
> the >gcc31 selection for the CPU?  Better yet, why not post the .config
> from the 3 kernels?
They were on, configs no longer available other than some notes I took
at the time.  Again, not really relevant in the original context of the
test - next time as it seems people are interested.
>  
> > 3. optimisations were EXACTLY as recommended by both the make.conf
> > entries, which were supported by the cflags from the forum for this cpu:
> > a 2G celery (P4 based core)  I am not sure now, but I believe I ran
> > prelink as well (to match mandrake) - need to find and check the notes.
> > 4. Gnumerics problems have been identified and come down to the
> > particular version - is fixed in the upcoming stable release even before
> > this was found, but the project was unaware that what they believed was
> > a slightly slower mod in this version, could be so bad on particular
> > data sets - i.e., 30 odd mins in 1.0.13, but is less that 30s on 1.0.19
> > on my laptop
> 
> I hope you only used optimizations listed in the forums for the actual
> version of GCC you're running.  From the sounds of it, you did not since
> you used pentium3 and the pentium4 problems were fixed in the most
> recent stable GCC.  
Not fixed in the version at the time of the tests.  Also, in my current
make.conf, there is still that huge all capital warning saying dont use
pentium4 - nothing about any safe gcc version for the P4.

> You also should have definitely used a "default"
> Gentoo install with no changes made.  The default profile setup would
> have been used instead.  Your optimizations could have been researched
> from GCC rather than taking the word of a bunch of "armchair compiler
> experts" on the forums.  No offense meant to anyone, but you mention
> below that you do much scientific work, yet followed a very poor
> scientific model and research documentation for this article, which is
> why it has been torn apart so adamantly.  Had you given out all of the
> information, even if it were simply links to the files from within the
> article, it would have given your article much more credibility.
> 
I actually did quite a lot of looking at this.  The flags used are a bit
different to what I use on my own  pentiums and athlons (I use
-fomit-frame-pointer for instance) - we limited ourselves to what the
user would see reading make.conf as suggested in the documents.
I would make the point that this is not an exhaustive no holds barred
competition -  Criteria could be described as "This was originally set
up as a simple test of 3 relatively new to the distro users installing
for the first time.  i.e., if I moved from RH to gentoo, where would I
start: read through make.conf which is where the docs say to go and set
the system up that way and so on." 

I agree it is not a "scientific test", - it was not meant to be, but a
simple this one looks faster than that one when I do the same work I do
every day - not a special performance suite.  We are not trying to be a
microsoft and come up with an unreal figure to bolster our sales.

> > There seems to be quite a few myths about this test and people upset
> > that months were not spent tuning gentoo and every effort made to
> > cripple the competition! (one person even suggested the faulty ide cable
> > should have been left in the debian box, as that was the way it was
> > delivered!)  Read the article, and if you need extra information to
> > reproduce it, email me or or the author (Indy).  It is reproducable - if
> > you can obtain the same hardware - I would be very interested if someone
> > has this and the time to really go into the why these results occurred
> > in more detail than I had the chance to.
> 
> The same machine should have been used for the testing, rather than
> three machines.  This alone is reason enough to discount your data. 
> Three different machines WILL have three different levels of
> performance.
> 
A couple have mentioned this, but from personnel experiance, I can say
yes, you may see some small variations (other than actually faulty
hardware), but they should be fairly close if using the same software. 
We were not using the same software, so I would expect that to submerge
any variations in hardware

> > and why was this the result?  Daniel Robbins suggested on this list that
> > gentoo-sources may be the problem, but tests on another machine (we had
> > the trial machines for only a couple of days, all of which time was used
> > to build gentoo right up until I ctrl-c'd the OO build so we could do
> > the tests before handing the hardware back) showed that turning off
> > pre-empt and low-latency had zero effect, but changing to an open-mosix
> > kernel 2.4.20  was ~10% slower (no thread export).  It seemed to come
> 
> I agree with Daniel on some of this.  The default Gentoo kernel is not
> the fastest out there, it is the most feature rich to meet the various
> needs of our user base.  I do agree that this kernel should have been
> used rather than any other.  Also, preempt and the low-latency are
> interactivity increases, not raw performance increases.  Their
> modifications are not easily quantifiable.  If you want to test them, I
> suggest you look into ConTest
> (http://members.optusnet.com.au/ckolivas/kernel/) which was designed for
> testing this sort of thing.
> 
I dont use conftest in my day to day work, but I often use gnumeric,
gimp and OO - the intention was not to test for pure numbers but for me
at least, If I wait for 30 mins to load my spreadsheet under Gentoo, how
much longer will poor debianites have to wait ... and the answer was not
as long! - so the focus shifted to whats gone wrong with gentoo.

connftest will be handy when tuning for the next one (depending on
time), but I doubt will be used for actual benchmarks as it is
irrelevant to everyday use.
> > down to the fact we used -O3 instead of -O2 (think spider might have
> > suggested this ?)- in effect over-optimised, and we didnt have a chance
> > to correct. From my perspective, most of the "he should have used ...
> 
> No, you definitely "should have used" -O2 rather than -O3.  Also,
> -fomit-frame-pointer and -mfpmath=sse would have given dramitic
> improvements.  I'm not going to go into any other optimizations because
> the rest are essentially very specific to the hardware/software being
> used.  I think these are the only "sensible" extra defaults that can be
> used on a machine with SSE.
Couldn't use them as they were not listed as reccomended in make.conf.

Keep in mind that pentium3 implies extra flags - the following is from
an email on the gcc list:
-march=pentium3     -mcpu=i686 -msse
-march=pentium4     -mcpu=pentium4 -msse2

so sse is implied by pentium3, and sse2 is where the invalid code 
was being generated, hence the warning to stay away from pentium4!

> 
> > may actually have made performance even worse! And besides the time
> > issue, these were supposedly the safe, reccomended flags so we went with
> > them.  Please note that even Mandrake made only a slight gain on debian,
> > so 386.586/686 does not make a lot of difference in real world tasks
> > (the original aim of the tests) - the tests did tasks that particular
> 
> 386, 586, 686 make little difference compared to 386, 586, pentium4,
> which is how it should have been.
> 
> > people used linux for in their day-to-day work - no special tests, so no
> > special bias.  Yes, I could choose tests that make gentoo shine, or
> > debian, or windowsXP.  But I dont do those tests every day, whilst that
> > spreadsheet was/is used as part of my normal work.  And its the same
> > with the other tests.
> 
> I actually agreed with most of your tests.  You had a hard time being
> very time constrained.  Honestly, were I in your position, I would not
> have made this report at all unless I had a MUCH longer time to test
> things.  You should look into the kinds of testing that many of the
> hardware sites out there use.  They tend to take WEEKS on a single
> article.  It doesn't take their full attention that entire time.  After
> all, there's only so much interaction you need to do when running a
> script which performs hundreds of actions and logs results to a file.
> 
A bit late, as you can only find out this after you start the test - not
cricket to say whoops, I'm not winning, go ahead without me! : so gentoo
didnt perform up to my hopes.  At least we now have a discussion as to
why, how to improve it, and perhaps reel in some of the hype.

> > So how many gentoo systems out there have every possible optimisation in
> > the book, and are actually running slower than ideal?  This is a real
> 
> I use quite a few optimizations, which I benchmarked on my machine with
> my application/data set and it is the fastest I was able to come up
> with.  I have actually turned OFF quite a few of the optimizations
> recommended by many of the "airmchair compiler experts" out there
> because they either provided little to no improvement or actually
> decreased performance.  I really don't care if something is 0.001%
> faster if it takes 400% as long to compile.  Especially being a
> developer and compiling quite a bit of stuff several times over.
> 
> > problem, and I will be interested in how the cflags projects around
> > handle this, as most seem to aim at setting the maximum possible flags:
> > not actually tune the system for the ones that work best/most stably.  A
> > live benchmark test might be more appropriate.
> 
> I agree 100% here.
Thanks, hopefully this article has kicked this idea along a bit.
> 
> > Most posts on irc and lists have settled down to "he doesnt know what
> > he's doing" (I do), or the tests were unfair to gentoo (they werent, but
> > then the same criteria were met by all 3 systems, but with some question
> > marks over debian because of its mix - some packages had to be compiled
> > locally, not binary) - but the thrust of the article was not that gentoo
> > was a dud, but that this was the result within the criteria and time we
> > were given, not what we expected, so we need to find out why.  Also note
> > that this was not intentionally a debian/mandrake/gentto distro test.
> 
> Not being able to tune Gentoo essentially means you did not participate
> in the "Gentoo Approach" but rather kludged it together fairly untuned
> and pitted against a tuned binary installation and debian.
> 
> > We may be getting a P4 hyperthreaded system to play with, but under
> > different rules, where I get to do a bit of tuning first.  I have
> > already built the core system on another machine using gcc-3.2.3,
> > "-march=pentium4 -O3 -pipe -fomit-frame-pointer"  I note that the
> > pentium4 warning still appears in make.conf, though I believe it no
> > longer applies to this gcc.
> 
> It does not apply to the newest stable GCC, so you are correct.
> 
> > A while ago I emailed this list and asked for information on tests and
> > settings for HT P4's, without a reply.  So again, has anyone done any
> > tests on a HT P4 and is willing to support the flags they chose as being
> > "the best"?  In particular, does -ffast-math give a measurable gain? 
> 
> There is not much in the way of HT as it is looked at as a SMP machine
> under Linux.  All you really do is enable SMP and make sure you use ACPI
> in the kernel.  The default Gentoo kernel does not have many of the HT
> scheduling changes which have gone into the making of the 2.6_test
> kernels.  There are backports for these, but I would consider that going
> a bit overboard, as hand-patching your kernel sources would yield better
> results on all three systems and should be left alone.  After all,
> you're wanting to test the results of the three systems, not of your
> hand-made kernel.  If you were to decide to use another kernel, I would
> say to use the latest vanilla kernel and possibly the latest 2.6_test
> kernel on each distribution using the exact same .config to see how much
> the kernel makes a difference in performance.  You should not use
> -ffast-math in anything as a default, as it causes math errors which
> should not be introduced into a stable system.
> 
> > Most of my machines have been built as scientific stations, so accuracy
> > is more important than ultimate speed, so this is one I have never
> > tested.  I am not interested in the -O9 -max-everything kiddies who have
> > been so vocal, but reasoned choices.
> 
> The -O9 kiddies are the "armchair compiler experts" I spoke of earlier. 
> They have zero real knowledge of compilers and optimizations at all, but
> have "heard from a friend" or "read on a forum" about it so they think
> they know it all.  I will gladly admit that I know little about
> compilers, but I have taken the time to do actual benchmarks on my
> system to test my various theories and have chosen what I feel to be the
> best combinations for my own needs.
Wish more would do as you have done - I dont think too many follow this
approach.  Most seem to just do the reccomended, or go for the max.  I
did a few key apps, made my choices and have stayed with them.  If a
really useful cflags project gets up, it would be nice to run it
regularly and perhaps find that the new gcc just emerged gives a
measured 5% speed up if you use the new -supercharger flag!

I accept there can be a large number of criticisms made of the tests,
but most can be countered because of the criteria we set for ourselves.

Thanks for the time you spent on this

-- 
William Kenworthy <billk@iinet.net.au>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentooapproach)"

[matt c]

Sorry for butchering your email, I only wanted to ask the list about one
point I saw that you made.

----- Original Message ----- 
From: "William Kenworthy" <billk@iinet.net.au>
Subject: Re: [gentoo-dev] "Distro Day (Measuring the benefits of the
Gentooapproach)"
<snip>
> Wish more would do as you have done - I dont think too many follow this
> approach.  Most seem to just do the reccomended, or go for the max.  I
> did a few key apps, made my choices and have stayed with them.  If a
> really useful cflags project gets up, it would be nice to run it
> regularly and perhaps find that the new gcc just emerged gives a
> measured 5% speed up if you use the new -supercharger flag!

I think that this is where the confusion with many "experts" on optimization
lies. What is a good program to use as a benchmark for optimizations and
compiler flags? How does one measure the performance gain? Is the
performance gain just in load time, or in processor usage throughout the
program? Do the benefits of using a particular optimization translate from
one program to the next? Some programs are snappier with -O2, some perform
twice as quick with -O3. Who is to say? How does one know for certain?

 I have found that, for the most part, -O2 compiled apps runs much faster on
my system. I don't have any hard numbers, but I do know I decided to rebuild
my system recently with just -O2 ,-pipe, and -fomit-frame-pointer only -
Everything I do seems to be a bit more responsive.

>From what I've been hearing, I think the general consensus is that -O2 seems
to be a better optimization than -O3 *in general, for the most people*, yes?
Right now the "Decent examples" in make.conf include (in both examples) -O3
as the optimization level to use. If -O2 is that much better, would it not
be the sane thing to recommend to users who read make.conf to use -O2?

I don't know - do -finline-functions and -frename-registers really make that
much of a difference? I am no expert at compiler internals. I only know what
has been my experience and what others say.

Just a thought.

Matt



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[FRLinux]

On Wed, 2003-08-13 at 23:49, William Kenworthy wrote:
> I posted this to the gentoo-user list by mistake last night (it was
> after midnight and ...) - wondered why I didnt get too many
> flames/replies!

Glad to know you were actually 'one of us' as in, you took time to get
information on what should be set on the Gentoo make.conf file.

> 3. optimisations were EXACTLY as recommended by both the make.conf
> entries, which were supported by the cflags from the forum for this cpu:
> a 2G celery (P4 based core)  I am not sure now, but I believe I ran
> prelink as well (to match mandrake) - need to find and check the notes.

Having read a couple of posts before yours, i'm quite scared to learn
that prelink could lead to an unstable system. I've never emerged it on
my gentoo and was considering doing so, anyone could enlighten me on the
possible risks on this ? I am looking at more stability over speed
improvements and have been very satisfied with my 1.4rc3 install so far.


> So how many gentoo systems out there have every possible optimisation in
> the book, and are actually running slower than ideal?  This is a real
> problem, and I will be interested in how the cflags projects around
> handle this, as most seem to aim at setting the maximum possible flags:
> not actually tune the system for the ones that work best/most stably.  A
> live benchmark test might be more appropriate.

CFLAGS are the key-point to my knowledge, i am not a compiler specialist
but i don't even put specific optimisations anymore on my Gentoo, just
keep -march=athlon-xp -03 and that is all.
 
> Most posts on irc and lists have settled down to "he doesnt know what
> he's doing" (I do), or the tests were unfair to gentoo (they werent, but
> then the same criteria were met by all 3 systems, but with some question
> marks over debian because of its mix - some packages had to be compiled
> locally, not binary) - but the thrust of the article was not that gentoo
> was a dud, but that this was the result within the criteria and time we
> were given, not what we expected, so we need to find out why.  Also note
> that this was not intentionally a debian/mandrake/gentto distro test.

Well you have to admit that reading the test doesn't give a lot of
informations about what was done ... This is where people begun picking
on you. If that had been a bit more detailed, the feedback would have
been better i'm sure, exactly as you have currently done with your post.

> If you want to flame, go ahead - but support your statements!

No flame concerning myself, i'm glad to have a better understanding of
what was done. Plus you are not the first one mentioning that Gentoo
depending on its optimisations (read my words on this : depending) is
slower than Mandrake for instance (which has done quite a nice job
lately on speed).

Steph
-- 
Mail sent on Gentoo 1.4rc3 k2.6-test3 AMD 2600+
http://frlinux.net - frlinux@frlinux.net
http://gentoofr.org - Portail Francais sur Gentoo Linux




--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[William Kenworthy]

I have the uxury of an old cyrix 233 system for testing.  Before
prelink, OO took 1 minutes 8 seconds to startup, and afterwards ~45
seconds.  Testing was done by doing a clean reboot to eliminate
cacheing, then start OO immediately after loging in.  repeat to confirm
it.  I then prelinked, rebooted and repeated.  Tested for a few weeks to
make sure no problems surfaced, then did two other systems.

I now have 3 systems prelinked (the cyrix, athlon t-bird1.4 with a flaky
abit MB, running at 1.2G, and a dell P4M laptop - all totally stable.  2
are heavily used (the athlon is my home
desktop/firewall/webserver/mail/dns/etc, and the laptop is my work
machine.

Unexpectedly (but I havent measured it), starting OO when a copy is
either running or recently closed, its very noticeably faster than the
same circumstances before prelink - almost stunningly in fact.

You can un-prelink a running system (or problem apps), but I havent
found that neccessary.

BillK

On Fri, 2003-08-15 at 03:22, FRLinux wrote:

> Having read a couple of posts before yours, i'm quite scared to learn
> that prelink could lead to an unstable system. I've never emerged it on
> my gentoo and was considering doing so, anyone could enlighten me on the
> possible risks on this ? I am looking at more stability over speed
> improvements and have been very satisfied with my 1.4rc3 install so far.
> 
> 



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[David Holm]

[-- Attachment #1: Type: text/plain, Size: 1056 bytes --]

If they really wanted to test the speed why didn't they use more aggressive compiler flags?

I think it should be investigated which packages could be compiled by icc since
intel are now providing it for free for non-commercial use. I did some tests with it and
whetstone (classic fpu benchmark from the 1970's) doubled in speed compared to gcc on a P4, and
it was about 75% faster on an Athlon-XP. Now float-point isn't everything but from my experience
icc generally produces better optimized code than gcc unless the application has been hand-tuned
(like mplayer).
I tried installing gentoo with CC=icc once but I had problems with many ebuilds so I dropped
that idea. At the moment extremely few ebuilds support icc.

//David Holm

On 13 Aug 2003 15:38:21 +0200
Philippe Lafoucrière <lafou@wanadoo.fr> wrote:

> http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1



[-- Attachment #2: Type: application/pgp-signature, Size: 187 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Philippe Lafoucrière]

On Wed, 2003-08-13 at 16:24, David Holm wrote:
> If they really wanted to test the speed why didn't they use more aggressive compiler flags?
> 
> I think it should be investigated which packages could be compiled by icc since
> intel are now providing it for free for non-commercial use. I did some tests with it and
> whetstone (classic fpu benchmark from the 1970's) doubled in speed compared to gcc on a P4, and
> it was about 75% faster on an Athlon-XP. Now float-point isn't everything but from my experience
> icc generally produces better optimized code than gcc unless the application has been hand-tuned
> (like mplayer).
> I tried installing gentoo with CC=icc once but I had problems with many ebuilds so I dropped
> that idea. At the moment extremely few ebuilds support icc.


Just realized that they are using march=pentium3, whereas celeron is a pentium2 (cf /etc/make.conf !). 
the use of march can really slow down the machine I think...


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Eric Olinger]

On 13 Aug 2003 16:28:53 +0200
Philippe Lafoucrière <lafou@wanadoo.fr> wrote:

> Just realized that they are using march=pentium3, whereas celeron is a pentium2 (cf /etc/make.conf !). 
> the use of march can really slow down the machine I think...

It depends on the Celeron. IIRC the Celerons up to 533MHz are based on the P2 core, the Celerons from there 
up to 1GHz are based on the P3 core and the Celerons over that are based on the P4 core. Their the same 
as the chip their based off of but with about 1/2 the on die cache and the FSB is clocked slower.

-- 
Eric Olinger (http://evvl.rustedhalo.net/pgp_key.txt)


The cure for 1984 is 1776.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Jon Portnoy]

On Wed, Aug 13, 2003 at 04:24:32PM +0200, David Holm wrote:
> If they really wanted to test the speed why didn't they use more aggressive compiler flags?
> 
> I think it should be investigated which packages could be compiled by icc since
> intel are now providing it for free for non-commercial use. I did some tests with it and
> whetstone (classic fpu benchmark from the 1970's) doubled in speed compared to gcc on a P4, and
> it was about 75% faster on an Athlon-XP. Now float-point isn't everything but from my experience
> icc generally produces better optimized code than gcc unless the application has been hand-tuned
> (like mplayer).
> I tried installing gentoo with CC=icc once but I had problems with many ebuilds so I dropped
> that idea. At the moment extremely few ebuilds support icc.
> 

That's because there's no reason each and every ebuild needs to have 
something changed when most of the time 'supporting icc' is just a 
matter of altering the usual environment variables...

At the moment Zadeh and einride are working on ICC integration. einride 
has some excellent ideas about Portage integration, so hopefully that'll 
get us somewhere.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Mike Frysinger]

On Wednesday 13 August 2003 15:00, Jon Portnoy wrote:
> At the moment Zadeh and einride are working on ICC integration. einride
> has some excellent ideas about Portage integration, so hopefully that'll
> get us somewhere.

hopefully the idea isnt icc-centric ... that is, it'll support say uclibc 
compiler, or dietlibc, or tcc, or what have you :)
-mike

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 'Distro Day (Measuring the benefits of the Gentoo approach)'

[donnie berkholz]

On Wednesday 13 August 2003 15:02, Mike Frysinger wrote:
> On Wednesday 13 August 2003 15:00, Jon Portnoy wrote:
>> At the moment Zadeh and einride are working on ICC integration.
>> einride has some excellent ideas about Portage integration, so
>> hopefully that'll get us somewhere.
>
> hopefully the idea isnt icc-centric ... that is, it'll support say
> uclibc  compiler, or dietlibc, or tcc, or what have you :)
> -mike

Perhaps gcc-config should be expanded to toolchain-config ...



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 'Distro Day (Measuring the benefits of the Gentoo approach)'

[Jon Portnoy]

On Wed, Aug 13, 2003 at 08:07:20PM -0500, donnie berkholz wrote:
> On Wednesday 13 August 2003 15:02, Mike Frysinger wrote:
> > On Wednesday 13 August 2003 15:00, Jon Portnoy wrote:
> >> At the moment Zadeh and einride are working on ICC integration.
> >> einride has some excellent ideas about Portage integration, so
> >> hopefully that'll get us somewhere.
> >
> > hopefully the idea isnt icc-centric ... that is, it'll support say
> > uclibc  compiler, or dietlibc, or tcc, or what have you :)
> > -mike
> 
> Perhaps gcc-config should be expanded to toolchain-config ...
> 

In the past the plan has been to move gcc-config to cc-config and modify 
it to support other compilers.

einride had some thoughts about Portage modifications instead, but I 
haven't really been keeping up with what's going on there.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] 'Distro Day (Measuring the benefits of the Gentoo approach)'

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 352 bytes --]

On Wed, 2003-08-13 at 21:07, donnie berkholz wrote:
> > hopefully the idea isnt icc-centric ... that is, it'll support say
> > uclibc  compiler, or dietlibc, or tcc, or what have you :)
> > -mike
> 
> Perhaps gcc-config should be expanded to toolchain-config ...

Or possibly just cc-config...

-- 
Chris Gianelloni
Developer, Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Stuart Herbert]

[-- Attachment #1: signed data --]
[-- Type: text/plain, Size: 928 bytes --]

On Wednesday 13 August 2003 2:38 pm, Philippe Lafoucrière wrote:
> here is an article comparing debian / mandrake / gentoo speed :
>
> http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=inde
>x&req=viewarticle&artid=227&page=1http://articles.linmagau.org/modules.php?o
>p=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1

Old news.  Was covered on Slashdot back on August 2nd.  Study is flawed in a 
number of ways, and anyway - the best reason to run Gentoo is "no more RPM's" 
;-)

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Beta packages for download            http://dev.gentoo.org/~stuart/packages/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Svyatogor]

As someone mentioned correctly this test is not reproducible. I could equally 
come up with a simmilar test, which would swap some columns in their results. 
Furthermore, this looks more like an anti-advert of Gentoo, cause these guys 
claim that there is a diff of up to 3-4 times. I was using Mandrake of my 
machine before I moved to Gentoo and I can tell you Gentoo is at least as 
quick as Mandrake, and even quicker.

On Wednesday 13 August 2003 16:38, Philippe Lafoucrière wrote:
> here is an article comparing debian / mandrake / gentoo speed :
>
> http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=inde
>x&req=viewarticle&artid=227&page=1http://articles.linmagau.org/modules.php?o
>p=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1
>
>
>
> --
> gentoo-dev@gentoo.org mailing list

-- 
Let the Force be with us!
Sergey Kuleshov


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] "Distro Day (Measuring the benefits of the Gentoo approach)"

[Adam Porich]

On 13 Aug 2003 15:38:21 +0200
Philippe Lafoucrière <lafou@wanadoo.fr> wrote:

> here is an article comparing debian / mandrake / gentoo speed :
> 
> http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1http://articles.linmagau.org/modules.php?op=modload&name=Sections&file=index&req=viewarticle&artid=227&page=1
> 

I'm sorry to mention this again but the speed of a distribution is more than what benchmarks can show, I have seen a few benchmarks come out in the past few days that say that gentoo performace is less than satisfactory. But, I can say that having used my gentoo desktop for some time, and having used many others. I consider my gentoo desktop to be much faster and more responsive than others. The point is how fast a desktop is, is often a personal measure and not an easily quantifiable measure.

P.S. The init scripts and other built-in scripts are so much better that I don't care about performace under gentoo anyway.


--
gentoo-dev@gentoo.org mailing list