From owner-freebsd-hackers@FreeBSD.ORG Thu May 15 15:56:26 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 C67F437B401; Thu, 15 May 2003 15:56:26 -0700 (PDT) Received: from haldjas.folklore.ee (Haldjas.folklore.ee [193.40.6.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id C04C343F75; Thu, 15 May 2003 15:56:25 -0700 (PDT) (envelope-from narvi@haldjas.folklore.ee) Received: from haldjas.folklore.ee (localhost [127.0.0.1]) by haldjas.folklore.ee (8.12.3/8.11.3) with ESMTP id h4FMuO6U094178; Fri, 16 May 2003 01:56:24 +0300 (EEST) (envelope-from narvi@haldjas.folklore.ee) Received: from localhost (narvi@localhost)h4FMuOxd094175; Fri, 16 May 2003 01:56:24 +0300 (EEST) Date: Fri, 16 May 2003 01:56:24 +0300 (EEST) From: Narvi To: Marcel Moolenaar In-Reply-To: <20030515221503.GC821@athlon.pn.xcllnt.net> Message-ID: <20030516012353.U40030-100000@haldjas.folklore.ee> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: freebsd-performance@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: Thu, 15 May 2003 22:56:27 -0000 On Thu, 15 May 2003, Marcel Moolenaar wrote: > On Fri, May 16, 2003 at 12:26:19AM +0300, Narvi wrote: > > > > > If you set yourself some simple goals and keep it high-level, then > > > we can all get used to the idea and we will probably find other > > > opportunities while we go. The end result can be much the same as > > > you try to achieve now, except that it has a bigger chance to be > > > integrated rather than some weird bunch on the side that plays > > > with compiler options "and shit". > > > > nah, don't be too hard on them. they are volunteering for a large amount > > of hard work 8-) > > Hard work it is, but the question of timing pops up: when there's > so much that needs to be done functionality-wise, how does the > hard work relate to progress? Of course, this being a voluntary > project, people are free to spend their time on things they like > to do. But with freedom comes opposition -- or something along > those lines :-) Ultimately, they have to prove themselves and make sure what they produce gets used - otherwise they fail. > > If I would be asked to sacrifice implementation flexibility at a > time when things may need to be rewritten a couple of times to get > it right (think new platforms), I will be mostly insensitive to > arguments that limit that flexibility in favor of performance. > But if they are going to do this they don't understand how the project works, and will probably fail at any rate. > This is the root of my concern. Any team that seperates itself as > one that focusses on performance, is one that finds opposition and > the opposition may be too large to be able to do any performance > related work. It has to come natural, like enforcing style(9), or > security. Not that enforcing style(9) is without friction. But it's > a well-known and (almost :-) acceptable part of development. I > think performance has to be that too if we don't want it to be a > constant source of conflicts. > > If a performance team could achieve that, then we're in for a > winner. /me thinks, Yes, true. But its not a simple target 8-) > > -- > Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net >