This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++ libtool lossage
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, Mark Mitchell <mark at codesourcery dot com>, gcc-patches at gcc dot gnu dot org
- Date: Sun, 24 Feb 2002 18:19:14 -0500
- Subject: Re: libstdc++ libtool lossage
>>>>> Jakub Jelinek writes:
Jakub> Show me a system where it doesn't matter.
Jakub> Over 80% of shared libraries on typical Linux system are plain C shared
Jakub> libraries. Having every such shared library linked against
Jakub> libgcc_s.so means every program is linked against it.
Jakub> I cannot imagine how you can manage to avoid a couple
Jakub> of non-shareable dirty pages per every single process, a bunch of
Jakub> system calls and relocation/symbol lookup costs per each
Jakub> process just because of libgcc_s
Jakub> (which is usually not used at all, worst case some divide routine or
Jakub> something (but those are usually already exported from glibc)).
Depending on libgcc.so does matter on all systems. The question
in my mind is the price relative to other performance impacts -- the
startup cost versus the cost of the extra page frames and page table
entries for divide, mod, and truncate routines duplicated in each
executable and shared object. That memory pressure and VM overhead has a
cost when those routines are present in a large number of programs and
libraries in the system.
I do not know which cost is more without experimentation. The
price may be close and comparable. I do not think the answer is obvious.
This may be another case of different optimizations for desktop versus
enterprise computing.
David