number crunching

[Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>]

There has been some talk on this newsgroup about Dylan replacing C as
a system's programming language.  In addition to this, I would like to
see Dylan serve as a scientific computing language.  I would love to
see Dylan be that language (it's so darn elegant), but there are many
problems with Dylan that, in my opinion, make it too slow for these
applications.

There are two major problems with the current design that I would like
to point out in this letter: (1) representation of numbers and (2)
dispatching on numbers.  I suggest the addition of the short-float
representation and parameterized classes to alleviate some of Dylan's
short-comings.  I would appreciate comments on how to achieve the same
effect in the current Dylan.

Representation:

Dylan desperately needs a short-float representation so as to
alleviate the need to cons floats on call to and return from methods.
This float consing problem plagues LISP implementations and keeps it
from being a serious number-crunching language.

This short-float lack is exacerbated by a lack of a floating-point
vector type.  Imagine having to store boxed floats in a vector for
computing serious matrix operations, it would cons tremendously!  This
is what a programmer would have to use with the current Dylan design.
With a short-float, at least the programmer could store the floats
directly in the vector (without pointers).

It's clear that the short-float would not suffice for serious number
crunchers who demand even more precision.  I guess with current
compiler technology, one can at least compile away the pointers in the
code of a particular method -- the problem is the storage format and
the consing that happens when a method calls another method with float
args and/or return values.  Perhaps some of this overhead goes away
with frozen classes.

Dispatching:

Suppose one wanted to write an efficient matrix object that would work
for a variety of element types.  As it stands now in Dylan, one would
declare the elements as numbers, for example, and then write the
matrix methods to operate on matrices of numbers.  Unfortunately, this
would be very slow, because code inside these methods would
necessarily have to dispatch on all numeric arithmetic.  

The obvious thing to do is to then write a separate matrix class and
separate methods for each different type of number (i.e., one for
complex, one for real, one for integer, one for fixpoint, etc.).  Then
all the methods would have the proper types and the compiler could
inline all the arithmetic and the code would run nearly as fast as C.

The problem with this approach is that the user has to meticulously
copy and type each of the methods.  This is completely dissatisfactory.
An alternative approach found in OOSL's (e.g., C++, Eiffel, and
Sather) is to parameterize the class by the type of the element.
These classes get instantiated at compile time and separate copies are
automatically generated with the proper typing.  This makes it very
convenient to construct very efficient objects.

Parameterized classes would also help in solving the first problem,
because one could create a parameterized vector class.

----

What are other people seeing in Dylan that I'm missing.  How is Dylan
going to achieve the same kind of efficiency as C++ or Sather for
number crunching or systems applications?

-- jonathan bachrach

IRCAM
31, rue Saint-Merri
F75004 Paris, France
011-33-1-44784864
bachrach@ircam.fr