Subject: Re: proposal: libcc1 -> static
To: None <tech-toolchain@netbsd.org>
From: Ian Dall <Ian.Dall@dsto.defence.gov.au>
List: tech-toolchain
Date: 01/05/1999 17:15:32
Todd Vierling <tv@pobox.com> writes:
> On Sun, 3 Jan 1999, David Brownlee wrote:
> : Wasn't one of the ideas behind going to libcc1.so to share memory
> : between different passes of the compiler to make using pipes
> : feasible. (The whole point being to speed up compiling).
> Demand paged VM == for the same language, you get this benefit anyway.
He is talking different phases, not different instances of the same
compiler.
> Remember that binaries' text pages are shared, even between different
> invocations, as well as unmodified data pages. A shared object actually
> slows down each invocation because of all the reloc fixups. Christoph
> drilled this reminder into me. :>
> It's only when you heavily mix languages that you get a speedup with the
> shared object, and then, it's not much of a speedup.
With static linking there will be no sharing of pages between cc1, as
and ld which you might want if you are using the -pipe option.
However, I don't really think -pipe is very good anyway and instead
avoid disk traffic by making TMPDIR a memory file system.
> : The disk space savings have to be pretty small - we currently link
> : four binaries {cc1,cc1obj,cc1plus,f771} against libcc1 (which is
> : around 1.4MB on an i386 system). I don't know how much of the
> : library is used by each binary.
It isn't just *disk* space. Depending on your job mix it can also save
RAM. It can I believe also make the RAM situation worse (more pages
touched) so there is no simple best solution.
Ian