> On Sep 18, 2017, at 4:52 AM, Sam Tobin-Hochstadt <sa...@cs.indiana.edu> wrote: > > Just so you know, typed/racket/no-check is not a typed language -- everything > is turned off except the syntax.
Right; I wanted to try disabling contract checking per Robby’s suggestion, and I figured that no-check would accomplish that; I realize that it’s a "what’s-the-upper-limit-on-this" measure, not a long-term solution. John > > 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.
