From: Paul de Vrieze <pauldv@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Do we want optimal performance?
Date: Thu, 9 Sep 2004 09:52:51 +0200 [thread overview]
Message-ID: <200409090952.51315.pauldv@gentoo.org> (raw)
In-Reply-To: <33543.10.0.0.51.1094653278.squirrel@10.0.0.51>
On Wednesday 08 September 2004 16:21, Klavs Klavsen wrote:
>
> I do realise there wouldn't be much point in doing this
> flag-optimization for every package - but I'm sure everybody could
> benefit greatly from this for servers, with MySQL, PostgreSQL, apache
> etc. etc. Would be nice with if this resulted in a set of optimal
> CFLAGS (as fast as possible, without stability problems) and perhaps
> some performance CFLAGS (with perhaps some stability problems) for
> these packages (for each CPU-type) - so people know what they are
> doing.
Well, find out what is the way to get them as fast as possible, submit
that to the upstream developers so they can overlay that upon the default
cflags. Then everybody is happy, including gentoo as it does not cause us
extra support or testing headaches.
> It would in esssense be a record of "automated performance testing
> numbers" with "unstable CFLAGS added, if not detected with automated
> performance testing, then added via bugzilla.
Read a bit up on complexity theory, will you.
> IMHO a very good start would be with tests for the major serverpackages
> (as they are the easiest to do test-suites fore - and most likely we
> can already find test-suites for these) and then go from there.
> To most, they won't care if bzip2 is a little slower - but they would
> care, if their LAMP setup was quicker for the same buck :)
Providing this will add major complexity to the packages and portage. The
only thing that might help is the arc profiling stuff. The rest is at
your own leisure. profiling and improving code in any case is more likely
to lead to significant speed increases.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2004-09-09 7:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-08 10:15 [gentoo-dev] Do we want optimal performance? Klavs Klavsen
2004-09-08 11:29 ` Paul de Vrieze
2004-09-08 12:03 ` Corvus Corax
2004-09-08 13:16 ` Paul de Vrieze
2004-09-08 12:19 ` Alin Nastac
2004-09-08 13:24 ` Marcus D. Hanwell
2004-09-08 13:43 ` Patrick Lauer
2004-09-08 14:21 ` Klavs Klavsen
2004-09-09 7:52 ` Paul de Vrieze [this message]
2004-09-08 12:49 ` Spider
2004-09-08 17:16 ` Robert Moss
2004-09-08 18:20 ` Chris Gianelloni
2004-09-08 19:11 ` Klavs Klavsen
2004-09-08 19:54 ` Paul de Vrieze
2004-09-08 20:05 ` Marcus D. Hanwell
2004-09-08 19:41 ` Lisa Seelye
2004-09-09 0:49 ` Daniel Goller
2004-09-09 1:51 ` [gentoo-dev] per package cflags (was Re: Do we want optimal performance?) Travis Tilley
2004-09-09 2:26 ` Robin H. Johnson
2004-09-09 3:42 ` Ned Ludd
2004-09-09 3:49 ` Robin H. Johnson
2004-09-09 17:23 ` Robert Moss
2004-09-09 4:41 ` Will Buckner
2004-09-09 4:51 ` Ciaran McCreesh
2004-09-09 6:07 ` [gentoo-dev] Do we want optimal performance? Klavs Klavsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200409090952.51315.pauldv@gentoo.org \
--to=pauldv@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox