The ``optimized'' figure reflects conservatively where I expect things will end up. I've only included it where the number of IPC operations is small and their interactions (e.g. in the cache) are well understood.

The ``predicted'' figures show where I think we're going to end up, but in these cases the systemic effects are harder to predict and the number should be viewed as a reasonable expectation.

Some fine print on the individual benchmarks:

• The ``trivial system call'' is intended to measure the cost of entering and exiting the supervisor while doing essentially no work within the kernel. The nearest equivalent EROS operation is that ``get capability type'' operation, which is actually more complex.

  All EROS kernel entries have the same API, and all of them therefore check the passed arguments. There are semantic arguments for why this is the right thing to do, and in real programs it doesn't seem to cost much. Still, it does lead to misleading answers for this benchmark.

• The ``null I/O'' call is intended to measure the cost of entering and exiting the supervisor and actually doing something small but useful. In the UNIX case it's a zero-length read from /dev/null. In the EROS case it's a zero-length read from a page capability.

• Growing the heap may not seem like an important operation, but it's surprising how much of program startup time is determined by this operation -- zeroing the BSS section, for example, can be quite costly. Mostly, though, it's not important in UNIX because it's plenty fast enough.

  In Mach, the experience was that the external pager made things terribly slow, so it was important to us to know whether this was the case in EROS. Fortunately, it doesn't appear to be a bottleneck, and remember that this is the slow IPC!!!

• Page fault latency is misnamed; it actually measures the cost to reconstruct page tables after remapping a previously unmapped file. What this measurement shows is that EROS works hard not to throw such things away, and consequently reconstructs them very quickly.

• The pipe latency number looks worse than it is, because it is heavily influenced by the IPC speed. The test is measuring the time to transfer a single byte across the pipe boundary, and small transfers are very much dominated by the underlying IPC implementation.