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 <mfl...@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. _________________________________________________ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
