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 <[email protected]> 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" <[email protected]> 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 <[email protected]> >> 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 < >>> [email protected]> 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 >>>> <[email protected]> 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 [email protected]. >>>> > 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 [email protected]. >>>> 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 [email protected]. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
