John,<br><br>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<br>
<br>> cpu time: 94 real time: 94 gc time: 0<br>
> cpu time: 79 real time: 78 gc time: 0<br>
> #t<br><br>
On 5.0.1.900 I get the following run times:<br><br>cpu time: 203 real time: 203 gc time: 0<br>cpu time: 94 real time: 94 gc time: 0<br>#t<br><br>I see similar results on my other tests<br><br>I'll see what I get with the #:flat keyword next.<br>
<br>Doug<br><br><div class="gmail_quote">On Fri, Oct 22, 2010 at 9:31 PM, Doug Williams <span dir="ltr"><<a href="mailto:m.douglas.williams@gmail.com" target="_blank">m.douglas.williams@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
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.<br>
<br>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.]<br>
<br>Anyway, if it isn't too late, I think swapping the definitions would make more sense and be safer.<br><font color="#888888"><br>Doug<br><br></font><div class="gmail_quote"><div>On Wed, Oct 20, 2010 at 8:56 AM, Matthew Flatt <span dir="ltr"><<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>></span> wrote:<br>
</div><div><div></div><div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>At Wed, 20 Oct 2010 07:48:20 -0700, John Clements wrote:<br>
><br>
> On Oct 20, 2010, at 7:39 AM, Doug Williams wrote:<br>
><br>
> > I downloaded the pre-release version this morning - 10/20 (I believe it was<br>
> a build from 10/16). The plot package and plot extensions in the science<br>
> collection all work as expected. But, I am getting different numeric answers<br>
> for some of my science collection routines (for example, the gamma function)<br>
> and some of my newer code (for example, FFT) either fails with an error<br>
> message or DrRacket just dies. All of this code uses unsafe operations and the<br>
> problem may lie there somewhere. I'll try digging more deeply this evening.<br>
><br>
> Focus first on uses of unsafe-vector-ref and unsafe-vector-set!. (Not the fx<br>
> and fl variants, just the plain ones). I wound up removing these from the FFT<br>
> code in order to get it to work.<br>
><br>
> Check out bug PR 11264.<br>
><br>
> Also, very late flash of insight: my response (getting rid of<br>
> unsafe-vector-ref and unsafe-vector-set!) might explain my performance issues<br>
> with the FFT library.<br>
<br>
</div>Overall, keep in mind that changes to vector contracts mean that<br>
vectors can be wrapped with chaperones. That's why `unsafe-vector-ref'<br>
may need to change to `unsafe-vector*-ref', and it may explain<br>
performance differences in general.<br>
<br>
</blockquote></div></div></div><br>
</blockquote></div><br>