(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.
