[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: dylan scientific/multimedia
- To: email@example.com
- Subject: RE: dylan scientific/multimedia
- From: Jonathan Bachrach <Jonathan.Bachrach@ircam.fr>
- Date: Wed, 7 Oct 1992 16:28:30 +0100
- In-reply-to: Simon Spero's message of Tue, 06 Oct 92 20:41:08 -0400 <9210070041.AA06973@SunSite.unc.edu>
Thank you for all the responses in favor of addressing the numeric
processing needs. Future technologies demand high performance numeric
processing and it would be short-sighted to not think carefully about
what is needed to get the high-performance demanded of these
applications (e.g., multi-media).
I truly think it is a mistake to just fall back on a FFI (C) for one's
numeric processing needs. This is gross and forces THOSE developers
to lose all the advantages of an OODL, the advantages that are so well
articulated in the introduction to the Dylan book. It definitely
warrants some deep thoughts about how to adapt Dylan for these needs.
I am convinced that Dylan can meet the needs of these users without
major changes: changes that I think would also benefit other users of
Date: Tue, 06 Oct 92 20:41:08 -0400
From: Simon Spero <firstname.lastname@example.org>
[meta-note: I only just got added to the lists, so I'm still not 100%
up to speed- are the archives available for WAIS/FTP anywhere?]
email@example.com (John Lewis) writes:
>Are there currently any Lisp implementations which do floating point
>very efficiently? I don't know of any, so I'm not expecting this
>from Dylan either, but it would be nice.
If there's sufficient type information available at compile-time, lisp
is as fast as fortran. It's only when the types are unknown and you have to
dispatch at run-time that things really start to slow down.
This is exactly the point that I've been trying to make in my series
of messages: Dylan needs to go all the way with its type system. This
is the point of introducing types for key-values, rest args, define's,
and for introducing parameterized classes. Without the type
information, Dylan is doomed to be slower (e.g., dispatch and cons).
(One way to avoid this overhead would be to use a radical compiler
technique (dynamic compilation) as done in SELF, but I still think
that the resulting code will be slower than Fortran).
>- That Dylan provide for homogeneous arrays of short floats and ints.
> If not, vectorized coding can still be done by allocating foreign storage
> on the heap and manipulating this with the C-coded vector ops.
> Someone borrowed my Dylan manual, so i don't know if this is possible.
Unboxed vectors would be a big win for small datatypes. At the moment the
only types for which this has been defined are char and unicode-char; a new
subclass of vector which only allowed objects from a single class to be stored
in it would be a big win.
Parameterized vectors would serve this purpose. Instead of having a
special vector type for all basic objects, one could have a
parameterized class. The syntax might be `(<vector> <char>)' for a
vector of characters, `(<vector> <int>)' for a vector of integers, and
`(<vector> <single-float>)' for a vector of floating point values. I
could give more details...
Incidentally, whilst we're on the subject of types; unless I'm missing
something, Dylan doesn't seem to have an equivalent to Common Lisp's
'the'; I guess this can be simulated by having a macro wrap a bind around the
expression, but it'd be nice to have something semi-standard.
If the type information were available then I don't think `the' would
31, rue Saint-Merri
F75004 Paris, France