From owner-freebsd-current@FreeBSD.ORG Wed Nov 26 11:52:03 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 8641916A4CE for ; Wed, 26 Nov 2003 11:52:03 -0800 (PST) Received: from harmony.village.org (rover.bsdimp.com [204.144.255.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDB2F43F85 for ; Wed, 26 Nov 2003 11:52:01 -0800 (PST) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.9p2/8.12.9) with ESMTP id hAQJq1lg053183; Wed, 26 Nov 2003 12:52:01 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Wed, 26 Nov 2003 12:51:38 -0700 (MST) Message-Id: <20031126.125138.133913249.imp@bsdimp.com> To: kutulu@kutulu.org From: "M. Warner Losh" In-Reply-To: <20031126144357.GK15294@wombat.localnet> References: <20031126052320.GH15294@wombat.localnet> <20031126144357.GK15294@wombat.localnet> X-Mailer: Mew version 2.1 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: 40% slowdown with dynamic /bin/sh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Nov 2003 19:52:03 -0000 In message: <20031126144357.GK15294@wombat.localnet> Michael Edenfield writes: : time make -j 4 buildworld Hmmm, more jobs. : They were on a single CPU Athlon 500 with 320MB of RAM. 320MB is not enough RAM not to swap. I did some preliminary testing last night (which I lost due to a crash) that showed that a simple 'make buildworld' slowed down 1-2% depending on how many times I ran them. However, make -s buildworld (with or without -j 4 on my dual athlon) was faster than a normal buildworld, but the dynamic /bin/sh was more like 5-7% slower. The difference here is that there are fewer context switches (and I guess less chance for parallelization). In all make buildworld, the number of page faults was 10x for the dynamic case than for the static case. However, having said that, I think everybody realizes the following: 1) Dynamic linking is slower. 2) Speed improvements in this area are possible, as demonstrated by other projects. 3) PIC code is slower than non-PIC code, in general, and also gcc runs about 5-10% slower depending on if you are running out of a shared library or a static one. shared libraries must use PIC code (at this time). 4) People like to complain. Warner P.S. One interesting note: /bin/sh when linked statically with libedit and libncurses but dynamically with libc runs about 10% slower for my /usr/bin/true/true tests than when all three are dynamically linked. So it seems that not all dynamic linking is bad for performance.