Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 21 Apr 1997 11:39:44 -0700 (MST)
From:      Terry Lambert <terry@lambert.org>
To:        abelits@phobos.illtel.denver.co.us
Cc:        james@westongold.com, freebsd-hackers@freebsd.org
Subject:   Re: Price of FreeBSD (was On Holy Wars...)
Message-ID:  <199704211839.LAA13979@phaeton.artisoft.com>
In-Reply-To: <Pine.LNX.3.95.970421092604.14219A-100000@phobos.illtel.denver.co.us> from "Alex Belits" at Apr 21, 97 09:47:00 am

next in thread | previous in thread | raw e-mail | index | archive | help
> > >   Oh, that can justify inefficiency in kernel.
> > 
> > I'm not sure I understand you.  Adding such code *shouldn't* cause
> > inefficiency. 
> 
>   Then it's invalid justification. Or you mean that supporting
> interpreters can be an _excuse_ to have the rest of system inefficient?

Why is it that modularity implies inefficiency to you?  This is a bad
Aristotilian mean... you are using logic like:

if A implies B,
	then B implies A

And that's false logic (consider A='is a trout' and B='is a fish').

The only conclusion you can draw from increased modularity is that
the modularity will be increased.  You can't draw any conclusions
about efficiency whatsoever.


I recently ran lmbench against a system with and without my namei
changes (as an example).  With the changes, the VFS interface is
definitely more modular.  But there is no impact whatsoever on
the lmbench results for this increased modularity.  The layering
violations in the existing namei are inactive violations, not
active once (ones which intentionally make the violation for an
increase in speed).


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704211839.LAA13979>