From owner-freebsd-hackers Thu Aug 28 08:25:05 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA04112 for hackers-outgoing; Thu, 28 Aug 1997 08:25:05 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA04102 for ; Thu, 28 Aug 1997 08:24:59 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.6/8.8.5) id KAA02038; Thu, 28 Aug 1997 10:24:36 -0500 (EST) From: "John S. Dyson" Message-Id: <199708281524.KAA02038@dyson.iquest.net> Subject: Re: shared libraries? In-Reply-To: from Alfred Perlstein at "Aug 28, 97 09:13:27 am" To: perlsta@sunyit.edu (Alfred Perlstein) Date: Thu, 28 Aug 1997 10:24:36 -0500 (EST) Cc: hackers@FreeBSD.ORG Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Alfred Perlstein said: > > if you are running 50 processes, let's say that that 25 of them are > unique, well ok, now whichever duplicate processes you have around share > TEXT and unmodified DATA, however, if shared libs were used ALL processes > could share a majority of TEXT, that TEXt being the standard library > routines. > > Feel free to slap me now :) > Slap!!! (I liked SEF's explanation). When I said locality of reference, it begs the issue that everything is linked in. That increases the cache footprint, and code/data/bss size. For trivial programs, shared libs are almost always a win if you don't run them too often. Shared libs are in a fixed linking order, with lots of extra stuff, including sparse .data and .bss, due to all of the routines being linked in. That is evil, taking up extra cache lines (32bytes/line on a P5/P6, and more on other architectures.) Imagine on a P6 where you have a 8K/8K BYTE L1 (fast) cache. It means that you really have a 256/256 cache line (item) cache!!! A couple of years ago, we started linking the GCC as a shared program (CC1, CC1PLUS being linked against the GCC backend and utility routines.) The compiler slowed down significantly (more than just measurable -- it even felt slower.) -- John dyson@freebsd.org jdyson@nc.com