Aubrey Jaffer wrote:
> "Branch Prediction and Interpreter Speed"
> <http://swiss.csail.mit.edu/~jaffer/CNS/interpreter-branch>

The first two paragraphs of that article's conclusion read as follows:
> For an interpreter, using branch prediction to prevent speculative
> fetches can make generic arithmetic operations as fast as
> typed-restricted ones.
>
> As a result, the SRFI-77 type-specific duplicate arithmetic
> functions have motivation only for Scheme compilers. Type
> information for compiling is commonly supplied thorugh type
> declarations. It is incumbent upon SRFI-77 to justify its
> approach versus type declarations, which it doesn't mention.

That first paragraph is moderately interesting, but is not
particularly relevant to SRFI-77.  It appears to me that
the second paragraph implicitly rests on three questionable
assumptions:

1.  Speedups that are achievable only by compilers are not
particularly important.
2.  Speed is the primary rationale for the type-specific
operations described in SRFI-77.
3.  The common way of doing things is the best way to do
them in Scheme.

Assumption 1 does not require a response.

Assumption 2 is, in my view, false.  In my view, the primary
rationale for the type-specific operations is to improve the
portability and predictability of Scheme code.  The fixnum
and flonum operations do that by providing a portable base
for a portable implementation of the full numeric tower.
This will allow Scheme programmers to use generic arithmetic
without worrying about implementations that don't provide the
full tower, and the fixnum-specific operations will allow
those who are already using fixnum-specific operations or
implementations to do so more portably.  The primary rationale
for the other type-specific operations is to address some of
the portability and predictability issues that were raised
in the paper by Egner et al.

As for assumption 3, type declarations cannot address the
portability and predictability issues unless implementations
are required to interpret those declarations in a consistent
way.  Given the expectations created by Common Lisp, many
Scheme programmers would make the mistake of thinking that
type declarations are for performance, and that interpreters
are free to ignore them.  Some implementors might make the
same mistakes, especially when you consider that requiring
implementations to pay attention to type declarations is
likely to make interpreters slower, not faster.

By the way, when speed is a goal, the Common Lisp experience
suggests that type declarations are often less effective than
type-specific operations, mainly because programmers would
rather write and read (fx+ (foo x) (baz y)) than
(the fixnum (+ (the fixnum (foo x)) (the fixnum (baz y)))).

Will