This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
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