[racket-dev] Release for v5.0.2 has begun

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.williams at 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.williams at 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 <mflatt at 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.
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20101023/88e05278/attachment.html>