From owner-freebsd-performance@FreeBSD.ORG Wed Jun 25 21:39:06 2003 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12E4A37B401 for ; Wed, 25 Jun 2003 21:39:06 -0700 (PDT) Received: from ns1.xcllnt.net (209-128-86-226.BAYAREA.NET [209.128.86.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 28A3D43FFD for ; Wed, 25 Jun 2003 21:39:05 -0700 (PDT) (envelope-from marcel@xcllnt.net) Received: from dhcp01.pn.xcllnt.net (dhcp01.pn.xcllnt.net [192.168.4.201]) by ns1.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5Q4ccDZ014706; Wed, 25 Jun 2003 21:38:38 -0700 (PDT) (envelope-from marcel@piii.pn.xcllnt.net) Received: from dhcp01.pn.xcllnt.net (localhost [127.0.0.1]) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9) with ESMTP id h5Q4cYhn033751; Wed, 25 Jun 2003 21:38:34 -0700 (PDT) (envelope-from marcel@dhcp01.pn.xcllnt.net) Received: (from marcel@localhost) by dhcp01.pn.xcllnt.net (8.12.9/8.12.9/Submit) id h5Q4cUZe033750; Wed, 25 Jun 2003 21:38:30 -0700 (PDT) (envelope-from marcel) Date: Wed, 25 Jun 2003 21:38:30 -0700 From: Marcel Moolenaar To: "D. J. Bernstein" Message-ID: <20030626043830.GA33650@dhcp01.pn.xcllnt.net> References: <20030625060629.51087.qmail@cr.yp.to> <20030625023621.N17881-100000@mail.chesapeake.net> <20030625094301.56349.qmail@cr.yp.to> <20030626025029.71392.qmail@cr.yp.to> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030626025029.71392.qmail@cr.yp.to> User-Agent: Mutt/1.5.4i cc: freebsd-performance@freebsd.org Subject: Re: ten thousand small processes X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jun 2003 04:39:06 -0000 On Thu, Jun 26, 2003 at 02:50:29AM -0000, D. J. Bernstein wrote: > Jon Mini writes: > > I'm sorry, but you are way off here. First of all, caches are *much > > larger* than the size of the processes you are talking about. > > I'm sorry, but you are being misled by a naive model of CPU performance. > On a typical Pentium in our department, the following program becomes > three times faster when SPACING is changed from 4096 to 128: *snip* > >From an asm programmer's perspective, when FreeBSD decides to spread a > small program's variables between > > * the beginning of a data page, > * the beginning of a bss page, > * the beginning of a malloc mmap page, > * the beginning of a heap page, > * the beginning of the next heap page, > * the beginning of yet another heap page, > > et cetera, it is actively trying (with varying degrees of success) to > damage cache performance in exactly the same way that this program does. Just curious: do you happen to know if the performance hit is caused by the second order effect of having the spacing be a multiple of the cache associativity, thereby resulting in thrashing of a few cache lines, and that compacting the code results in a more uniform cache placement? In other words: is it (sec) the spacing that counts or the interaction of a particular "distance" with cache placement? -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net