[linux-audio-dev] Hello - FYI - intro

[John Check]

On Wednesday 25 August 2004 02:41 pm, james at dis-dot-dat.net wrote:
> On Wed, 25 Aug, 2004 at 01:48PM -0400, John Check spake thus:
> <snip multiple levels of replies>
>
> > YES. This is a much better argument. If it wasn't for having to keep a
> > source respository (maybe it's optional) that would save disk space. I
> > used to mount the cache on an NFS share (only had a 20GB disk).
>
> I was going to say you could have a cron job that ran when nobody's
> likely to be using the machine that first checks to see if anything's
> being emerged and then deletes the source cache.  But then I realised
> two things.
>
> Thing 1: People will moan "But a newbie wouldn't want to mess..."

Newbie is beside the point. If somebody wants to make some tunage,
it gets in the way of getting started.

>
> Thing 2: Now that I think about it, I think there may be an option to
>         remove source tarballs when they've been used.  I don't
>   worry about disk space, so I've never looked into it.
>
> > Now if I had an office full
> > of clones and a build host, that's as good as it gets.
>
> If you're anything but a total newbie (and I doubt you are) then you
> can get some serious improvement in emerge times by using distcc.
>
> Does that sound complicated?  Here's how you do it.
>
> 1. Emerge distcc and configure it with distcc-config.  It's easy,
>    honest.

apt-get install distcc

Took < 30 seconds. ;) 
There's no way to get around it; To get all the advantages, you have to
invest significant time to reach peak performance.
Not to mention it blows the "software is free to produce" meme.
It takes a lot more energy to compile a binary than it does to copy it.
I'm not a tree hugger, but you can't argue with the physics.

> 2. In /etc/make.conf, add -jN to your MAKEOPTS.  N is the number of
>    simultaneous compilings you want.  It is suggested you use 2C+1,
>    where C is the number of CPUs you're using.  This goes for
>    non-distcc systems, too, unless you have old hardware.
> 3. In the same file, add "distcc" to your FEATURES variable.
>
> A more detailed how-to: http://www.gentoo.org/doc/en/distcc.xml
>

Yawn. I used to hack 2.0 kernel makefiles to speed the build up the same way,
but N was RAM-8/8. Either way, if the number of things that can be build 
concurrently is =< N , higher get you nothing.
The real irony is the machines that could benefit most are the most expensive 
ones to build on.

In their own doco, they say it's a build system (a damn fine one IMO) and IIRC 
they'd like to see it used for tasked tuned distro production.

> I used this for a while, but my other machine is too noisy to leave
> on (It's a HP Kayak xeon thing - the chassis is made of lead or
> something I think, and the fans sound like a vaccum cleaner) and my
> GF insists on using Windows.  Not just any old windows, either -
> Windows ME.
>
> <ricer>
> Maybe when I'm rich and have a herd of boxen, I'll do it again.  If
> for nothing else than to stand in the middle of the room and scream
> "The POWER!  The sweet intoxicating POWWWWEEEEEER!".
> </ricer>
>
> > > Personally, I don't bother, but that's where the real speed
> > > differences come from.  Absolutely nothing is installed unless you
> > > need it or asked for it.  No daemons floating around "just in case".
> >
> > Also a cogent point.
> >
> > > Anyway, I think I'll stop now.  If anyone knows where that article
> > > about the two emacs users comparing their systems is, please send me
> > > a link.
> > >
> > > James
> > >
> > > > Erik
> >
> > Me Too!