On Tue, Feb 25, 2014 at 9:32 AM, Matthew Flatt <mfl...@cs.utah.edu> wrote: > At Tue, 25 Feb 2014 09:22:54 -0500, Sam Tobin-Hochstadt wrote: >> On Tue, Feb 25, 2014 at 8:34 AM, <mfl...@racket-lang.org> wrote: >> > >> > eff53cd Matthew Flatt <mfl...@racket-lang.org> 2014-02-24 16:42 >> > : >> > | treat FFI primitives like other primitives internally >> > | >> > | This change paves the way for JIT-inlining FFI operations >> > | such as `ptr-ref`. Even without JIT treatment, the change >> > | slightly reduces the overhead for calling FFI primitives. >> >> Do you have benchmarks for the FFI that you used here? > > The claim of reduced overhead was based on removing indirections > through scheme_do_eval(), as visible in a low-level profile of a > drawing loop. > > Now that you ask, though, the change cuts about 25% of the time for the > loop below on my machine.
Nice! What code in the drawing loop were you profiling, though? I'm really looking for a larger-scale Racket program where the FFI is performance-important, rather than a micro-benchmark. Would the slideshow benchmark from our OOPSLA paper be a reasonable choice here? Sam > > ---------------------------------------- > > #lang racket/base > (require ffi/unsafe) > > (define N 1000) > > (define p (malloc N)) > > (time > (for ([i (in-range 1000)]) > (for ([j (in-range N)]) > (ptr-set! p _byte j 42)))) > _________________________ Racket Developers list: http://lists.racket-lang.org/dev