[plt-dev] performance-oriented unsafe operations (v4.2.1.8)

At Sun, 6 Sep 2009 14:22:34 -0600, Doug Williams wrote:
> These look like good things for me to use for efficiency in the science
> collection. Will these these be in the upcoming 4.2.2 release?

Yes, that's the current plan.

> I assume that if I use these and introduce a dependency on 4.2.2 or later
> that I should also bump the version number of the science collection in
> PLaneT - even if the interface remains the same. Does that make sense?

No, I think you wouldn't change the major version, since there's no API
change.

> I guess the term 'experiment' here confuses me. Is this something that might
> go away again? Should I wait until everyone is comfortable with the results?

Well, we need your help experimenting...

I think of it as an experiment in that I'm not sure that this is the
right approach for better performance. But it seems worth a try, and if
it works well for many purposes, then it'll stick.


> On Sun, Sep 6, 2009 at 12:27 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> 
> > Version 4.2.1.8 (now in SVN) starts an experiment with
> > performance-oriented unsafe operations.
> >
> > The new `scheme/unsafe/ops' library provides operations such as
> > `unsafe-vector-ref' and `unsafe-fl+' (for inexact real addition) that
> > are inlined by the JIT without contract checks. If a call violates the
> > contract of a function from `scheme/unsafe/ops', arbitrarily bad
> > things can happen. As long as contracts are satisfied, however,
> > performance should be a little better than with corresponding safe
> > operations.
> >
> > As part of the experiment, the expansion of `for' with `in-range' and
> > `in-vector' now uses unsafe operations (in a safe way). For example,
> > `in-vector' uses `unsafe-vector-ref' as well as a fixnum comparison
> > for detecting when it has reached the end of a vector; it also uses
> > unsafe fixnum arithmetic to increment the index as long as the step is
> > 1 or -1 (in which case no overflow can occur during the
> > increment). These improvements make a 10-20% difference in a tight
> > loop over a vector.
> >
> > Future possible directions include making the JIT specialize
> > combinations of inexact operations to avoid boxing intermediate
> > results.
> >
> > The exports of `scheme/unsafe/ops' are protected, so that a code
> > inspector can prevent access to unsafe operations by untrusted code.