[plt-dev] Release Announcement for v4.2.3, third call

Matthew,

I have updated several of the more computationally expensive components of
the science collection (e.g., Chebyshev approximations (which are used in
implementing many of the special functions), ordinary differential equation
solving (which is used in the simulation collection for continuous models),
and the statistics routines) to use the new unsafe operations. This does not
include the flvector operations, which I haven't played with yet. The
flvector operations should be easy to incorporate because I abstracted the
sequence operators into a dispatching version of the for and for/fold macros
that generate loops for lists and vectors as well as general sequences. I
can just add another case to the dispatching macros for flvectors.

The question is to what extent you guys as the development team still
consider these as experimental features. I have the code pretty well
protected against crashes from the unsafe operations. I would like to
release the updated science collection that uses them. But, if you think
they aren't ready, I'll hold off. I use them myself now without any
particular problems.

Doug

On Fri, Dec 4, 2009 at 2:47 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> At Mon, 30 Nov 2009 21:48:45 -0500, Sam TH wrote:
> > On Mon, Nov 30, 2009 at 9:34 PM, Matthew Flatt <mflatt at cs.utah.edu>
> wrote:
> > > At Mon, 30 Nov 2009 21:29:07 -0500, Eli Barzilay wrote:
> > >> [Matthew]
> > >> * scheme/unsafe/ops? (wasn't mentioned last time)
> > >
> > > I don't think any of these need to be in the release announcement.
> >
> > It seems like the unsafe operations are now a significant part of the
> > performance model, but they've never been announced more widely than
> > the mailing list.  Are we waiting for something?
>
> I think we're waiting until we've figured out how to use it well enough
> or packaged it better for a wide audience.
>
> The problem with local bindings that Will Farr pointed out is a good
> example of where support for unsafe operations needs improvement.
> Another good example is an experiment that I committed yesterday (which
> I know that you noticed): there's now an `flvector' type that avoids
> the two extra indirections of an `f64vector' in unsafe mode. The
> `flvector' operations are also inlined better in safe mode. But
> `flvector' works less well for FFI interactions, the safe operations
> are typically less efficient than safe operations on plain vectors, and
> even the unsafe operations offer a benefit only when combined with
> other operations to avoid unboxing.
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20091204/762c4513/attachment.html>