Re: [racket-users] TR for fast manipulation of C data

2017-09-18 Thread Matthias Felleisen
— I wonder if a slightly different choice of data representation could reduce the load on boundary crossing too. — And perhaps we can add 16bit data one day. > On Sep 18, 2017, at 12:28 PM, 'John Clements' via users-redirect > wrote: > > >> On Sep 18, 2017, at 4:52

Re: [racket-users] TR for fast manipulation of C data

2017-09-18 Thread 'John Clements' via users-redirect
> On Sep 18, 2017, at 4:52 AM, Sam Tobin-Hochstadt 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

Re: [racket-users] TR for fast manipulation of C data

2017-09-18 Thread Sam Tobin-Hochstadt
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

Re: [racket-users] TR for fast manipulation of C data

2017-09-17 Thread 'John Clements' via users-redirect
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

Re: [racket-users] TR for fast manipulation of C data

2017-09-17 Thread Phil Nguyen
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,

Re: [racket-users] TR for fast manipulation of C data

2017-09-17 Thread Sam Tobin-Hochstadt
`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" wrote: > (and (cast _ Positive-Fixnum) into (assert (assert _ fIxnum?)

Re: [racket-users] TR for fast manipulation of C data

2017-09-17 Thread Phil Nguyen
(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 wrote: > Simply changing all the casts (cast _ Natural) into (assert _ > exact-nonnegative-integer?), and

Re: [racket-users] TR for fast manipulation of C data

2017-09-17 Thread Phil Nguyen
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 wrote: > Maybe a first

Re: [racket-users] TR for fast manipulation of C data

2017-09-17 Thread Robby Findler
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 wrote: > I’m currently unhappy with the speed of rsound’s