25 Aug
2004
25 Aug
'04
5:30 p.m.
On Wednesday 25 August 2004 02:41 pm, james(a)dis-dot-dat.net wrote:
On Wed, 25 Aug, 2004 at 01:48PM -0400, John Check
spake thus:
<snip multiple levels of replies>
Newbie is beside the point. If somebody wants to make some tunage,
it gets in the way of getting started.
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..."
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.
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.
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. 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!