This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]