With the #:flat? keyword on the contracts and unsafe-vector-ref, etc, I get the following run times:
cpu time: 94 real time: 94 gc time: 0 cpu time: 63 real time: 63 gc time: 0 #t This is essentially the same run times as the 5.0.1 values. Doug On Sat, Oct 23, 2010 at 4:26 PM, Doug Williams <m.douglas.willi...@gmail.com > wrote: > John, > > In the FFT with unsafe-vector*-ref, etc substituted for unsafe-vector-ref, > etc, the run times are up to 100% greater. There may be places I can revert > to the unsafe-vector-ref, etc versions, but it would require an analysis of > the code that I don't have the time to do at the moment. I guess another > alternative is to keep the old behavior using the #:flat keyword on the > contracts. Using your test, I had the following on my laptop on 5.0.1 > > > cpu time: 94 real time: 94 gc time: 0 > > cpu time: 79 real time: 78 gc time: 0 > > #t > > On 5.0.1.900 I get the following run times: > > cpu time: 203 real time: 203 gc time: 0 > cpu time: 94 real time: 94 gc time: 0 > #t > > I see similar results on my other tests > > I'll see what I get with the #:flat keyword next. > > Doug > > > On Fri, Oct 22, 2010 at 9:31 PM, Doug Williams < > m.douglas.willi...@gmail.com> wrote: > >> Matthew, would it make more sense to have unsafe-vector-ref (and related >> functions) be the more general function and unsafe-vector*-ref be the one >> that doesn't work on chaperoned vectors? That is just swap the definitions. >> That way user code that is already using unsafe-vector-ref (etc) will >> continue to work. >> >> As it stands, existing code that has unsafe-vector-ref (etc) will often >> still work (in the sense of not getting any error or crashing), but just >> gives the wrong results. For example, if you run science-test.ss from the >> examples directory in the science collection, there are no errors. But, some >> of the answers are wrong - for example the very first one, the gamma >> function. [In other cases, like the FFT routines, there are either run-time >> errors or crashes.] >> >> Anyway, if it isn't too late, I think swapping the definitions would make >> more sense and be safer. >> >> Doug >> >> On Wed, Oct 20, 2010 at 8:56 AM, Matthew Flatt <mfl...@cs.utah.edu>wrote: >> >>> At Wed, 20 Oct 2010 07:48:20 -0700, John Clements wrote: >>> > >>> > On Oct 20, 2010, at 7:39 AM, Doug Williams wrote: >>> > >>> > > I downloaded the pre-release version this morning - 10/20 (I believe >>> it was >>> > a build from 10/16). The plot package and plot extensions in the >>> science >>> > collection all work as expected. But, I am getting different numeric >>> answers >>> > for some of my science collection routines (for example, the gamma >>> function) >>> > and some of my newer code (for example, FFT) either fails with an error >>> > message or DrRacket just dies. All of this code uses unsafe operations >>> and the >>> > problem may lie there somewhere. I'll try digging more deeply this >>> evening. >>> > >>> > Focus first on uses of unsafe-vector-ref and unsafe-vector-set!. (Not >>> the fx >>> > and fl variants, just the plain ones). I wound up removing these from >>> the FFT >>> > code in order to get it to work. >>> > >>> > Check out bug PR 11264. >>> > >>> > Also, very late flash of insight: my response (getting rid of >>> > unsafe-vector-ref and unsafe-vector-set!) might explain my performance >>> issues >>> > with the FFT library. >>> >>> Overall, keep in mind that changes to vector contracts mean that >>> vectors can be wrapped with chaperones. That's why `unsafe-vector-ref' >>> may need to change to `unsafe-vector*-ref', and it may explain >>> performance differences in general. >>> >>> >> >
_________________________________________________ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev