Date: Fri, 16 May 2003 01:56:24 +0300 (EEST) From: Narvi <narvi@haldjas.folklore.ee> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: freebsd-performance@freebsd.org Subject: Re: Optimizations. Message-ID: <20030516012353.U40030-100000@haldjas.folklore.ee> In-Reply-To: <20030515221503.GC821@athlon.pn.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030516012353.U40030-100000>