From owner-freebsd-current@FreeBSD.ORG Tue Nov 18 15:07:37 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4306E16A4CE for ; Tue, 18 Nov 2003 15:07:37 -0800 (PST) Received: from dyson.jdyson.com (dsl-static-206-246-160-137.iquest.net [206.246.160.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id C151443FBF for ; Tue, 18 Nov 2003 15:07:35 -0800 (PST) (envelope-from toor@dyson.jdyson.com) Received: from dyson.jdyson.com (localhost [127.0.0.1]) by dyson.jdyson.com (8.12.8/8.9.3) with ESMTP id hAIN7XXQ000718; Tue, 18 Nov 2003 18:07:33 -0500 (EST) (envelope-from toor@dyson.jdyson.com) Received: (from toor@localhost) by dyson.jdyson.com (8.12.8/8.12.8/Submit) id hAIN7Wpm000717; Tue, 18 Nov 2003 18:07:32 -0500 (EST) Message-Id: <200311182307.hAIN7Wpm000717@dyson.jdyson.com> In-Reply-To: <20031118.092100.108186967.imp@bsdimp.com> from "M. Warner Losh" at "Nov 18, 2003 09:21:00 am" To: imp@bsdimp.com (M. Warner Losh) Date: Tue, 18 Nov 2003 18:07:32 -0500 (EST) From: dyson@iquest.net X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit cc: dyson@iquest.net cc: current@freebsd.org Subject: Re: Unfortunate dynamic linking for everything X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: dyson@iquest.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2003 23:07:37 -0000 M. Warner Losh said: > In message: <200311181307.hAID7uHa032514@dyson.jdyson.com> > dyson@iquest.net writes: > : It really doesn't make sense to arbitrarily cut-off a > : discussion especially when a decision might be incorrect. > > I'd say that good technical discussion about why this is wrong would > be good. However, emotional ones should be left behind. Except for > John's message, most of the earlier messages have been more emotional > than technical. > > John, do you have any good set of benchmarks that people can run to > illustrate your point? > I'll see if I can find some of my old benchmarks (from memory, not disk -- lots of stuff has rotted away.). I had hoped to avoid doing much in the way of proof. Pointing to the much more complex process map along with the implication for significantly higher overhead :-). (The VM code generally gets slower with more complex process maps and more memory used. For smallish programs -- including those with a few shared libs, changing the VM code won't help much, because the cost is built in to the complexity of the process image.) If set-up correctly (trying to find facts, rather than proving a foregone conclusion), even the fork/exec tests on LMBENCH can be informative. The LMBENCH fork/exec benchmarks don't really measure EVERYTHING, and there appears to be a additional overhead beyond the old-time a.out, but they will likely still show some of the additional overhead. (Actually, simple fork/exec tests of simple programs don't show all of the additional overhead, and also bias the overhead results, but are one data point.) There might be a certain 'coolness' WRT dynamically linking everything, but the overhead is certainly measurable. If the object is to maximally 'share', then for shells the FreeBSD VM shares maximally without using shared libs (perhaps there is a lost know-how about how aggressively the FreeBSD VM implements parent/child and exec based sharing?) I'll try to put together a few simple benchmarks -- mostly from my defective memory. I had recently refreshed myself on this issue (but lost again due to disk hardware disasters and being clobbered by vinum problems -- which I have given up on.) Gimme a day or so -- I have several other things in my queue. John