Subject: Re: Is gcc slow? Or is our gcc slow?
To: None <current-users@NetBSD.ORG>
From: H. J|ngst, ISKP, Bonn <>
List: current-users
Date: 04/09/1996 18:34:12
> > Serious, I think it is time to make the change. Most systems have enough
> > memory today (but unixes can not handle it - oops :-). Disk I/O is a real
> > neck of a bottle in multiuser systems and therefore "-pipe" makes cc faster.
> > What's about the idea to make cc a little bit more intelligent and let it
> > decide alone if it should use pipes instead of disk I/O or not depending
> > on the remaining physical memory? Some statistics about the static and
> > dynamic memory usage calculated by the kernel would be very useful.
> Why make the decitions for a sysadmin, by encoding it in the system
> makefiles?

Why is -O in the system makefiles?

> Sounds Really Stupid, to me, especially when they have a very
> convenient way to "tune it" themselves.

"Convenient way" means you have to know this missing option and hack the

> In case it's not obvious: that way is "mount a MFS on /tmp if you have
> plenty of memeory."  If you don't have lots of memory, you don't want
> a MFS for /tmp, and neither do you want -pipe.  If you do have lots of
> memory, you get most of the majority of -pipe from MFS.

MFS is really stupid. You are wasting resources for the most of time.
"/tmp" and "/var/tmp" are stupid at all. Common temporary resources for
all users are the best way to produce problems. Some of them can not be
solved, of course. But others like common temorary scratch directories
are not neccessary.

If there is just one user who made a mistake and allocates the entire
space, then other users are not able to compile their program (and most
don't know why).

MFS means thinking like a MSDOS user.

> As somebody who has N machines which _don't_ have enough memory to use
> -pipe without severe slowdown, I certainly don't want it the default...

How much is not enough? Some Mbyte? Impossible to compile some Kbyte of
source code with some Mbyte memory?

The real reason is, that the current paging algorithm can not handle
the dynamic problem of memory allocation. Same is true for the rate
of task switches.

> (Actually, that won't really work, because, for some INCREDIBLY
> BONE-HEADED REASON, gcc puts its temporary files in /var/tmp...
> However, other things i've proposed, e.g. my /etc/mk.conf PR, would
> allow you to easily add -pipe to your system compiler flags, if you
> want it...)

/etc/mk.conf might be a solution. A tuning guide might be also interesting,
if the operation system can not tune itself (like others).

> cgd