From owner-freebsd-hackers@FreeBSD.ORG Fri May 16 00:42:25 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD76537B401 for ; Fri, 16 May 2003 00:42:25 -0700 (PDT) Received: from smtp-relay.omnis.com (smtp-relay.omnis.com [216.239.128.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E64C343FB1 for ; Fri, 16 May 2003 00:42:24 -0700 (PDT) (envelope-from wes@softweyr.com) Received: from softweyr.homeunix.net (66-91-236-204.san.rr.com [66.91.236.204]) by smtp-relay.omnis.com (Postfix) with ESMTP id 700EB1BA79; Fri, 16 May 2003 00:42:24 -0700 (PDT) From: Wes Peters Organization: Softweyr To: "Poul-Henning Kamp" , Narvi Date: Fri, 16 May 2003 00:42:23 -0700 User-Agent: KMail/1.5 References: <3641.1053034682@critter.freebsd.dk> In-Reply-To: <3641.1053034682@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200305160042.23636.wes@softweyr.com> cc: freebsd-hackers@freebsd.org Subject: Re: Optimizations. X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 07:42:26 -0000 On Thursday 15 May 2003 14:38, Poul-Henning Kamp wrote: > In message <20030516002105.K40030-100000@haldjas.folklore.ee>, Narvi writes: > >On Thu, 15 May 2003, Marcel Moolenaar wrote: > >> On Thu, May 15, 2003 at 02:30:33PM +0200, Pawel Jakub Dawidek wrote: > >> > Maybe is time to think about some 'optimiztion team' creation? > >> > >> I think I don't want to see this happen based on professional > >> experience. > > > >Well, supposedly any such team would need to start by creating a set > > of tools and benchmarks [...] > > If I have to be honest, I think this is the wrong way to approach the > subject, if on no other ground than on the 3. rule of optimizations > ("Don't do it yet"). > > While it would be nice to have a set of "blessed benchmarks" canned > and ready to run, we should learn from the lmbench fiasco in Linux > that such benchmarks can easier mislead than lead. > > My personal professional experience with optimizations or "Performance > management" as it was called, is that you want some very rigid > _functional_ testcases, which must pass at any one time so you don't > unnoticed loose functionality to optimizations. The best class of optimizations that can be made is fundamental algorithmic efficiency, rather than micro-optimizing poorly written code. > We also know that the main performance issue is Giant, Giant and Giant. Embracing and learning the locking code, then helping with the lock pushdown task, would be a worthwhile goal for some junior kernel hackers. It would also be a great learning experience. > So I really think the band of merry men we are talking about, if they > can be interested, would do much more good if they would start out > building functional and regression tests for our most critical > facilities. > > I can't speak for the other heavy-duty guys in the project, but I > would personally be _really_ _REALLY_ grateful if I could "cd > /usr/src ; make test" and know that a significant fraction of our > functionality worked if it returned a zero exit code. Yes, yes, and yes. Please note, folks, that this is coming from one of the few developers to bothers to implement test cases for his own code. -- Where am I, and what am I doing in this handbasket? Wes Peters wes@softweyr.com