Just so you know, typed/racket/no-check is not a typed language --
everything is turned off except the syntax.

Sam

On Sep 18, 2017 1:38 AM, "'John Clements' via users-redirect" <
us...@plt-scheme.org> wrote:

> Thanks to all of you; with casts changed to asserts, the use of
> unsafe-vector primitives, and changing the language to /no-check (which, if
> I’m understanding correctly, will disable contract checking as Robby
> suggests), resampling 15 seconds of audio goes from 1.2 seconds at the
> command line to 0.24 seconds, about 5x faster. That means about 1 second
> per minute, which essentially changes the time from “why is my computer
> taking forever to load this song” down to “oh, that’s not as snappy as it
> could be,” which is a vast improvement.
>
> Also, thinking about it harder, there’s no type in TR that corresponds to
> a signed 16-bit integer, so the type system isn’t going to have the tools
> to eliminate the range check anyhow; I have to go for the unsafe one if I
> want to avoid that check.
>
> Finally, *many* thanks for the clarification on the difference between
> cast and assert. Like Phil, I’m surprised that the cast can’t be optimized
> to the assert in the common case of the flat types, but I’ve discovered
> many times with TR that there are corner cases that I’m not thinking of.
>
> Best,
>
> John Clements
>
>
> > On Sep 17, 2017, at 21:16, Phil Nguyen <philnguyen0...@gmail.com> wrote:
> >
> > Each call in the program shrinked from ~20s to ~0.4s on my computer if I
> replaced all the casts with asserts. Given there's a correspondence between
> the two for base types, I wonder if existing gradually typed programs would
> benefit just from a more optimized expansion of `cast`.
> >
> > On Sun, Sep 17, 2017 at 9:39 PM, Sam Tobin-Hochstadt <
> sa...@cs.indiana.edu> wrote:
> > `cast` uses the contract system, which is harder for the compiler to
> optimize than `assert` which is just an if. At least that's my initial
> impression.
> >
> > Sam
> >
> > On Sep 17, 2017 9:27 PM, "Phil Nguyen" <philnguyen0...@gmail.com> wrote:
> > (and (cast _ Positive-Fixnum) into (assert (assert _ fIxnum?)
> positive?)). Somehow these make a huge difference.)
> >
> > On Sun, Sep 17, 2017 at 9:19 PM, Phil Nguyen <philnguyen0...@gmail.com>
> wrote:
> > Simply changing all the casts (cast _ Natural) into (assert _
> exact-nonnegative-integer?), and (cast _ Positive-Flonum) into (assert
> (assert _ flonum?) positive?) speeds up significantly for me.
> >
> > On Sun, Sep 17, 2017 at 9:11 PM, Robby Findler <
> ro...@eecs.northwestern.edu> wrote:
> > Maybe a first step is to just (unsafely) disable the contract checking
> > in order to see what the upper-limit of the improvement is.
> >
> > Robby
> >
> >
> > On Sun, Sep 17, 2017 at 8:07 PM, 'John Clements' via users-redirect
> > <us...@plt-scheme.org> wrote:
> > > I’m currently unhappy with the speed of rsound’s resampling. This is a
> pretty straightforward interpolation operation; if you’re not already
> familiar, imagine mapping an old vector ‘o' of size M onto a new vector ’n’
> of size N where each point ‘i’ in the new vector is obtained by linearly
> interpolating the two points of the old vector nearest to i*(M/N).
> > >
> > > Currently, it takes about 10 seconds to resample 60 seconds of audio,
> which I believe could be much much better. I bet that TR would help a lot
> here, but I’ve been poking around, and I don’t see any typed access to
> s16vectors or cpointers. I’m guessing that importing the ffi/unsafe
> functions with wrappers would be considerably slower...
> > >
> > > … well, I shouldn’t guess. I should try.
> > >
> > > AAGH! Yep, I was right. it goes 7x slower after naive conversion to
> TR. I could probably do better by working with the optimization coach, but
> I’m guessing that interposing the contract boundary on every read and write
> to the s16vector is a big slowdown that could easily be avoided. So: is
> there a good way to use TR for access to cpointers?
> > >
> > > I’ve attached the code in case anyone wants to see it; I don’t really
> care about the first call to (time …); it’s appallingly slow (20x slower in
> TR), but that’s not the part I’m trying to speed up. It’s the second call
> to (time…), around
> > > the resample call.
> > >
> > > John
> > >
> > >
> > >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > > For more options, visit https://groups.google.com/d/optout.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
> >
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "Racket Users" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to racket-users+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
> >
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to