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.

Reply via email to