[cap-talk] Object-capability vs. monolithic performance

[Jed Donnelley]

At 11:23 AM 1/4/2007, David Hopwood wrote:
>Jonathan S. Shapiro wrote:
> > Yes, we can achieve comparable performance with a comparably monolithic
> > and unprincipled design (as you apparently did), but in doing so we
> > would lose most of the benefit of object-capability systems.
>
>That's a considerable exaggeration. If everything but the GigE driver
>(and presumably some parts of the TCP/IP stack) is modular and isolated,
>how is that "losing most of the benefit of object-capability systems"?
>It just means that you have to review the monolithic code *very* carefully,
>to ensure that it is bug-free and equivalent to a modular and isolated
>design. For a small amount of code, this is feasible.

The above is what I believe as well.  Even for a relatively large amount
of modular code this is feasible.  As I noted in our case we could flip
a "switch" and run the corresponding code either in the modular
isolated architecture or munged together - still with the modular
architecture but with what amount to subroutine calls in the place
of IPC mechanisms - i.e. with internal domain boundaries between
what can otherwise be mutually suspicious "processes" (active
objects) lowered.

> >>Why is it that the [performance] comparison is between a
> >>"system S" built on a capability model and a native implementation
> >>of S, rather than comparable application run on a capability
> >>operating system, O?  Of course I understand the legacy issues,
> >>but if this is always the comparison then of course it will be
> >>impossible to compete.
> >
> > If you believe this, it's time to shut down cap-talk, because we are all
> > wasting our time. I don't believe this.
>
>Performance is not the be-all and end-all of OS comparison. (Nor is cap-talk
>just about capability operating systems.)

However, some of us (am I the only one?) yearn for a day when we at least
have interoperable object-capabilities at the network, OS, and language
levels.  This doesn't mean that they are identical nor that the "invoke"
call is the same on different systems (differing limits on data or capability
payloads are possible, different synchronization mechanisms, etc.) or at
different levels (which of course isn't possible), but that they are 
all wrappable
and mappable and mapped - so that they can be used across system
platforms and even produce what I believe would be a healthy competition
between interoperable object-capabilities.

For this dream to become reality it must be that it's possible
to design invocation interfaces so that all the objects they support
are wrappable and mappable with acceptable performance.  What
I've been arguing here is that (at least at the OS level, which seems
to be the most sensitive for some reason) this user visible interface
is not a relevant factor in performance considerations.  That is,
it is possible to design a wrappable/mappable object-capability
"invocation" call for any hardware architecture and to build an
implementation on it that supports all the services typically available
on today's market leading systems (Unix, Windows) with comparable
performance (latency, bandwidth, you name it) on the same hardware.
As noted previously and above, I consider "cheating" (lowering
internal domain boundaries) acceptable to achieve such a goal.
I view this goal as more relevant/important than that of achieving
competitive performance with internal domain boundaries raised if
it would mean the loss of wrappability/mappability at the user level
system call interface.

--Jed http://www.webstart.com/jed/