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

Re: small integers

    ....  As a user of
    a high level language, my strong preference is for clear statements within the
    language specification of what optimization statements I can use and what I
    should expect from them.  Make-read-only and seal are such optimization
    operations, though the manual does not explicitly tell me what optimizations I
    can expect given what situations.  Optimized numeric operations are a
    requirement for most commercial code, and users of a language must be able to
    write code that they can be confident will run very fast in any reasonable
    implementation of the language.
I think it would be a serious mistake for the Dylan language to include a
required list of numeric optimizations at this early point (or any time
very soon).  Until we all get some experience with this, it won't be clear
what is easy, what is straightforward but perhaps too expensive for small
implementations, and what is very hard.  At present, we don't yet have a
complete system of types and declarations, or even full agreement on how to
handle bignums/integer-overflow.

The langauge does require a few optimizations, such as tail-recursion
optimization, but those are special and generally well-understood cases.

What might be useful is for someone like you (perhaps in consultation with
Rob Maclachlan and other compiler wizards) to group the optimizations that
you want to see into a few coherent levels.  Then implementors and
applications designers would have a convenient shorthand: "This code runs
well only a in Dylan implementation with level 2 arithmetic optimizations."
You might even cook up a test suite for each level, though you'd have to
either look at generated code or do some tricky timing stuff to see if
certain operations are handled the way you want.

It wouldn't matter too much whether these levels are blessed officially as
part of the Dylan language or are just a users-group thing, as long as
everyone who wants to play this implementation efficiency game agrees to a
common set of conventions.

-- Scott
Scott E. Fahlman			Internet: sef+@cs.cmu.edu
Senior Research Scientist		Phone:    412 268-2575
School of Computer Science              Fax:      412 681-5739
Carnegie Mellon University
5000 Forbes Avenue
Pittsburgh, PA 15213