Subject: Re: [linux-audio-dev] Hello - FYI - intro
From: John Check (j4strngs_AT_bitless.net)
Date: Wed Aug 25 2004 - 22:13:25 EEST
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!
This archive was generated by hypermail 2b28 : Wed Aug 25 2004 - 22:20:01 EEST