number crunching

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

   According to moon@cambridge.apple.com (David A. Moon) on Mon, 05 Oct 92 16:42:21 EDT

>   I don't think anyone has proposed Dylan as a scientific programming language. 

There are a whole lot of applications that Apple works with that could
very much benefit from good floating-point performance.  Consider
hand-writing recognition (or speech recognition).  This seems to me to
be a crucial technology for Newton and future generations of Apple
computers.  Many of these algorithms use floating-point.  One
possibility is to use a fix-point representation, but it turns out
that for modern RISC processors, floating-point performance is often
better than fix-point performance.  One possibility is to call out to
C for these routines.  This is incredibly unappealing to me.  Like you
said, number crunching applications could benefit from the same
advantages that OODL's offer system's programmers.  It seems to me
that it is worth the effort to figure out how to make floating-point
performance good in Dylan.

>   One lower-level comment about your message: you need to be more clear on the 
>   distinction between the language and a particular implementation of the 
>   language.  You are assuming that the language is implemented a certain way and 
>   then criticizing the language on that basis.  But how can you be sure that 
>   that is the only way the language will be implemented?  Better either to 
>   criticize one particular implementation or to argue that the language as it 
>   stands cannot be implemented any other way and see if everyone buys that 
>   argument.

Please excuse any perceived confusion between implementation and
architecture.  In all fairness, it does appear that there are problems
with the efficiency of Dylan regardless of implementation.  

As far as floating-point goes, the only available Dylan floating-point
formats are the IEEE formats.  Given these formats there is no extra
room for a tag bit unless one's implementing this on a machine with
extra tag bits (which is assumed to not be feasible for almost all
implementations).  Alas, one is forced to implement <float>'s as
`boxed' entities (i.e., allocated on the heap) at least for <vector>'s
for example, because all objects in Dylan must be identifiable, either
by tag or object pointer (and there are no <float-vector>'s).  I
merely voice a need for one more format -- <short-float>, which in an
implementation could be the same as <single-float> (like in CL).

As far as parameterized classes go, the amount of dispatching is
crucial to performance.  The need for parameterized classes is in no
way limited to number crunching applications.  I happened to choose
this example.  It's a general technique for eliminating run-time
dispatching by introducing more type information and trading off code
size for execution speed.  Maybe there is a way to get parameterized
classes through the magic of macros.  It certainly wouldn't be as
integrated as parameterized classes in Sather, where classes are
automatically generated on demand at compile-time when referenced
(i.e., when a variable is declared with an instantiation of the
parameterized class).

-- jonathan

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