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

Re: --OMG_OPTIMIZED



On Fri, Apr 4, 2008 at 4:59 PM, Paul Johnson <baloo@ursine.ca> wrote:
> On Friday 04 April 2008 01:50:02 am Ivan Savcic wrote:
>  > On Fri, Apr 4, 2008 at 2:11 AM, Chris Walters <cjw2004d@comcast.net> wrote:
>  > > -----BEGIN PGP SIGNED MESSAGE-----
>  > >  Hash: SHA512
>  > >
>  > >  Ivan Savcic wrote:
>  > >  | Sorry for that personal message, I misclicked. It wasn't aimed at you
>  > >  | specifically.
>  > >
>  > >  Apology accepted.  I am sure most everyone, myself included, has made
>  > > similar
>  > >  mistakes.
>  >
>  > Thanks.
>  >
>  > >  | When Debian Etch was released, I wanted to give Debian a shot again in
>  > >  | some server scenarios, because of it's stability, security and ease of
>  > >  | upgrading. I now deeply respect the concept of "stable", having been
>  > >  | through security-through-bleeding-edge concept of Gentoo, for example.
>  > >  | Long End of Life of stable Debian seems priceless. Yet, on the other
>  > >  | hand, Backports filled the gap caused by some oldish packages and in
>  > >  | general there are a lot of packages for people to use.
>  > >
>  > >  I remember the days of Sarge.  I used backports then, as well as
>  > > compiling source.  Why?  Is it that I have a lot of time on my hands?
>  > > No.  It is/was to
>  > >  streamline the package, and optimize it for my processor.  The main
>  > > problem with precompiled distros, IMHO, is that because the packages,
>  > > especially the
>  > >  kernel, have to run on a multitude of different systems, they tend to be
>  > > larger
>  > >  and slower than if you compile those packages, optimized for your
>  > > system.
>  >
>  > Luckily, there are AMD64 and IA64 flavors of Debian. Shame there
>  > aren't (stable?) versions for i686, Athlon and P3/P4.
>
>  Do you have evidence that would justify this thinking?  Debian already has
>  packages optimized for sub-architectures, but only for the packages it
>  actually makes a difference on.  Optimizing the entire distribution is a
>  waste of DD time, and mirror diskspace for truly epsilon gains.

Long time passed since I was messing around with that, but give it a
shot yourself with Acovea[1], or if you manage to fix it, ccbench[2].
Way back, on my Gentoo Linux, I have concluded that -O2 makes a
difference compared to -O1 and i686 --mcpu/--march makes a difference
compared to i386. --fomit-frame-pointer also produced faster binaries.

[1] http://www.coyotegulch.com/products/acovea/
[2] http://www.rocklinux.net/people/clifford/ccbench/ccbench-0.2.tar.bz2


Reply to: