Public SourceMage Discussion List

[Thomas Orgis <thomas-forum AT orgis.org>]

Am Fri, 14 Nov 2008 15:07:53 -0600
schrieb "Javier Vasquez" <jevv.cr AT gmail.com>: 

> Yeap, that fixed the issue, although it's a pain fix, my machine is a
> p3 celeron @ 797.339 MHz with 32KB of cache, and 1594.67 bogomips, and
> 512MB of ram main memory, so compiling gcc/g++ took ~24 hours, and

Wow, that's massive. I had SMGL on a 366Mhz P2 laptop ... before that LFS...
And before that LFS on a 200Mhz P1; I remember KDE recompile taking a
weekend, yes, but a whole day for gcc/g++ is much time.
The time gcc needs for optimization has increased considerably, though.
I recommend turning _off_ speedy when you are limited (heh, as if that's
never the case) on CPU power.

Perhaps we should introduce a moderate archspec setting. -O3 needs
excessive compile time; something like -O2 or just -O seems to be much
more reasonable.
Of course there's always the folks voting for -Os, that's perhaps
another possibility to use. Anyhow ... On a system where compile times
make much of your day, overoptimization has no net benefit.

And, considering how gcc improves with possible optimizations like
vectorization (SSE), whole tree analysis, etc; one for sure has to
pay a price for that. And this is not exceptional to gcc: When you
crank up the optimization level on the Intel compiler (or Sun on
Solaris), it takes _time_ to complete the optimization.

> glibc + dependencies took ~ 12 hours as well...

Yeah, glibc is not that much of an issue once you got over gcc/g++;-)
Btw: I am really tempted to resurrect the whole-in-one gcc spell.
It can save a lot of time when updating gcc/g++/gfortran in a row.

> Now since both glibc and gcc/g++ were re-compiled, I'm doing sorcery
> -r which takes ~48 hours, and that just because I haven't installed
> applications yet (this is a recently installed box, for which I don't
> have applications yet)...

Well, this time should reduce considerably with -O1 or -Os, even.

Oh, and what I also recommend for systems that take a long time with
updating things (using that with a 700Mhz Athlon system): Have two
root partitions.
One for working, another for updating in chroot. After update: switch
partitions for booting, rsync the old one. Another benefit is that
you can safely continue using KDE while casting KDE (or anything)...

It may take a week for a system update to complete on said 700MHz Athlon,
but the user doesn't feel it too much thanks to nice level (and 768 MB RAM)
and even when they turn the machine off, I have configured software suspend
(tux on ice) to keep the tasks alive.
Though, I usually tell them to let the machine running during updates.


Alrighty then,

Thomas.

Attachment: signature.asc
Description: PGP signature