From owner-freebsd-current Thu Dec 2 8:21:33 1999 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9A4A214DC5 for ; Thu, 2 Dec 1999 08:21:28 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (beefcake.zeta.org.au [203.26.10.12]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id DAA00525; Fri, 3 Dec 1999 03:28:02 +1100 Date: Fri, 3 Dec 1999 03:20:57 +1100 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Ville-Pertti Keinonen Cc: current@freebsd.org, marcel@scc.nl, dillon@apollo.backplane.com Subject: Re: kernel: -mpreferred-stack-boundary=2 ?? In-Reply-To: <19991202150047.5370.qmail@ns.demophon.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 2 Dec 1999, Ville-Pertti Keinonen wrote: > > The times are for `time make depend; time make' after `make clean; sync; > > sleep 1' (2 times for each run). The stack may have been perfectly > > misaligned for the default gcc. > > It depends on the command line. It took me a while to figure out what > was going on the first time I benchmarked a program that ran much > faster when run under one name compared to when it was run using > another name... ;--) It also depends on the environment. The bw_pipe benchmark in lmbench is 20% (?) slower on some machines (P5's or K6/1's but not both) with certain enviroments and/or command lines, because it puts its buffers on the stack and the kernel doesn't bother to align the target addresses to more than 4-byte boundaries. > > Corresponding times for egcs with various PQ_L2_SIZE's a few months ago: > > Properly benchmarking page coloring can't be done in a straightforward > manner, since one of the desired effects is to prevent the page > selection behavior from degrading over time. Did you set up the > machine specially for those runs? I was improving page coloring, but wasn't very careful with those benchmarks, only with makeworld benchmarks. There was enough memory (320MB) to not stress my color allocator at all for kernel builds. That made kernel builds a bad benchmark for degradation of coloring but good for a quick test that color allocation hasn't become too expensive. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message