Re: small integers

[gensym!ireland!jra@harvard.harvard.edu (Jim Allard)]

   ...Dynamic development may not be the best modern development environment for such
   projects, then.  [a gasp escapes the studio audience]  The regression testing
   would have to be heavily compiled and optimized (read: static-ized) in order
   for such heavy-duty number crunching testing to be viable.

   Dylan may be, despite it's name [DYnamic LANguage], a suitable language for
   expressing such algorithms at some time in the future, but only if enough
   attention is paid to float optimization when writing the compiler...

   ...Hopefully, Dylan will come equipped with a foreign function interface that
   would allow the development of methods on these objects in a static language.
   I agree that this is not the best long-term direction, but languages that try
   to be everything for everyone end up like PL/I.

I must disagree with the content and sentiment of the previous statements.  Our
experiences with fielding a commercial product written in Common Lisp have been
dominated by the performance and portability concerns that are being
characterized as unimportant above.

Typically, it is has been easy for us to get our code to run within different
vendor's Common Lisps.  However, we have had to spend significant amounts of
time tuning it to run fast enough within these different Common Lisp
implementations.  In many cases we have been forced to use implementation
specific optimizations, such as foreign functions, to get the speed we needed.
Every time we have done this we have regretted it, either when it came time to
do the next port, or when previous ports were broken by the changes.

Usually the performance problems arose when implementations chose to ignore
type declarations that we expected would produce certain optimizations.  In our
case, we needed optimizations for the following: fixnum and double-float
arithmetic to get these operations in-line without boxing of intermediate
values; setting and fetching values within arrays of immediate double-floats
and immediate integers 1, 8, 16, and 32 bits in length; indirect dispatches to
functions where we knew the argument lists contained only required arguments;
and some miscellaneous fetching operations like (car (the cons x)) and (length
(the simple-vector y)).

There is always competition around speed in commercial software.  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.

There should not be a contradiction between ease of writing correct programs
and ease of writing fast programs.  The first is an advantage, while the second
is a requirement.

Jim

-------------------------------------------------------------------------------
Jim Allard                                        jra@gensym.com
Gensym Corporation                                (617) 547-2500
125 CambridgePark Drive
Cambridge, MA  02140
-------------------------------------------------------------------------------