[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fixnumXXX and fxXXX names, and other things

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.

On 18-Jun-06, at 1:47 PM, William D Clinger wrote:

Concerning duplicate names for operations such as fixnum< and fx<,
Marc Feeley wrote:
What is the rationale for all this duplication?

See the second rationale in the Fixnums section.

The rationale for the two sets of names is wrong. Adding redundant procedures adds confusion. For the trivial reason of avoiding bias toward either set of names the SRFI introduces 30 redundant bindings. These bindings have a cost in additional global variables, and in a system with precise error messages you actually need different procedures for the fixnumXXX and fxXXX procedures so that the error messages can indicate the name of the procedure that appears in the user program. Also, as I said in my previous message, the prefixes "fixnum" and "fx" give no clue to the nature of these operations (to me "fixnum" and "fx" are synonyms, better prefixes would be "fxring" and "fx"), so it is hard for the programmer to determine which one is the correct one to use.

The main motivation for fixnum specific operations is that
they are much faster than generic arithmetic.

That is one motivation, and for some people it may be the
main motivation, but it is not everyone's main motivation.

I didn't make this up. It is the only rationale for fixnums in the SRFI 77 rationale:

Fixnum/flonum arithmetic is already supported by many systems, mainly for efficiency. Standardization of fixnum/flonum arithmetic would increase the portability of code that uses it, but we cannot standardize the precision of fixnum/flonum arithmetic without making it
  inefficient on some systems, which would defeat its purpose.

Is there another rationale for fixnums?

By using a multiple values API for some fixnum operations, you are limiting the practical portability of those operations. This is inconsistent with the rationale. I repeat: in which implementations of Scheme will the multiple values API be faster than the equivalent pair of operations which return single values? I believe that efficient implementations of multiple values based on Ashley and Dybvig's method ("An Efficient Implementation of Multiple Values in Scheme" paper) will not gain with the MV API because they need to return the multiple values using a function call, and the overhead of the function call will drown the few machine cycles saved by the combined operation. The choice of a MV API for these operations is poor engineering.

But in many implementations of Scheme multiple values are
rather slow...

Presumably the operations that return multiple values will
be slow in those implementations.  Those who regard efficiency
as the main motivation for those operations might want to
avoid implementations in which multiple values are slow.

This view contradicts the rationale.

Finally, I haven't counted the number of procedures defined
in this SRFI, but it is clearly very high.  Do you
realistically think that current implementations of Scheme
will be updated to implement all these procedures efficiently?

Inasmuch as most current implementations have not yet gotten
around to implementing all of the R5RS procedures efficiently,
it would surprise me if they were to implement all of the R6RS
procedures efficiently.

My point is that this high barrier to entry will result in poor portability in practice. The prospects for portable and efficient arithmetic in Scheme would be greatly enhanced if the set of procedures to implement efficiently was small, because more implementations of Scheme would be willing to put the effort required to implement them. I have strong reservations about SRFI 77's "everything but the kitchen sink" approach. As an implementer, let me say that after all the effort put into the Gambit-C numerical library (roughly 8000 lines of Scheme code, with several fancy algorithms for bignum operations, representing months of work) I find SRFI 77's complexity to be a real turn-off when I consider the changes required to implement it properly. Surely I'm not the only implementer to feel this way.

Can we expect a portable and reasonably efficient implementation
of this SRFI to be written as the reference implementation?

Yes.  I'm working on it.

A relatively small subset of the fixnum and flonum procedures
will be identified as the basic primitives.  If implementors
implement those primitives efficiently, they will be rewarded
with a reasonably efficient implementation of the full SRFI.

Can you quantify what you mean by "reasonably efficient" for the fixnum operations? Do you mean as fast as the equivalent operation in C? Or maybe 2 times slower (which would still be reasonably efficient in my opinion)? I fear that unless the fixnum operations are inlined, the procedure call to the definition in the reference implementation will slow down the operation by a factor of 10 or more, rendering it useless in practice for writing efficient code.