[racket-dev] futures waiting for scheme_make_envunbox
While trying to use futures to parallelize a simple piece of code, I was able to remove all of the waiting except for this: future: 3 waiting for runtime at 1282743524205.783936: [scheme_make_envunbox] which happens continuously. What causes this function to be invoked, and how can I eliminate it? -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] futures waiting for scheme_make_envunbox
While we look into the other problems... What happens if you use `let' instead of the internal defines in `mandelbrot-point'? There's a `set!' implicit in the `letrec' that is implicit in the use of internal definitions. Maybe the Typed Racket optimizations confuse the compiler so that it doesn't see how to convert the `let' into a `letrec'. At Wed, 25 Aug 2010 10:07:04 -0400, Sam Tobin-Hochstadt wrote: On Wed, Aug 25, 2010 at 9:56 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 25 Aug 2010 09:42:40 -0400, Sam Tobin-Hochstadt wrote: While trying to use futures to parallelize a simple piece of code, I was able to remove all of the waiting except for this: future: 3 waiting for runtime at 1282743524205.783936: [scheme_make_envunbox] which happens continuously. What causes this function to be invoked, and how can I eliminate it? It happens when initializing a local variable that is assigned via `set!'. Probably we should inline scheme_make_envunbox() in JIT-generated code. Ok, that's kind of surprising. It seems that Typed Racket's optimizer is transforming the program in such a way that the bytecode compiler inserts `set!' where it wasn't before. I've attached the relevant file (which is just TR applied to the mandlebrot example from the futures paper). When the #:optimize keyword is used, the futures wait on `scheme_make_envunbox'. When it isn't used, there's much less waiting (just allocation and jitting). Unfortunately, trying to decompile this file produces an error in the decompiler: [sa...@punge:~/tmp plt] raco decompile mandelbrot.rkt hash-ref: no value found for key: 1128 so it's hard to tell exactly what's happening. -- sam th sa...@ccs.neu.edu -- [application/octet-stream mandelbrot.rkt] [~/Desktop open] [~/Temp open] _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] futures waiting for scheme_make_envunbox
On Wed, Aug 25, 2010 at 8:07 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Wed, Aug 25, 2010 at 9:56 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Wed, 25 Aug 2010 09:42:40 -0400, Sam Tobin-Hochstadt wrote: While trying to use futures to parallelize a simple piece of code, I was able to remove all of the waiting except for this: future: 3 waiting for runtime at 1282743524205.783936: [scheme_make_envunbox] which happens continuously. What causes this function to be invoked, and how can I eliminate it? It happens when initializing a local variable that is assigned via `set!'. Probably we should inline scheme_make_envunbox() in JIT-generated code. Ok, that's kind of surprising. It seems that Typed Racket's optimizer is transforming the program in such a way that the bytecode compiler inserts `set!' where it wasn't before. I've attached the relevant file (which is just TR applied to the mandlebrot example from the futures paper). When the #:optimize keyword is used, the futures wait on `scheme_make_envunbox'. When it isn't used, there's much less waiting (just allocation and jitting). Unfortunately, trying to decompile this file produces an error in the decompiler: [sa...@punge:~/tmp plt] raco decompile mandelbrot.rkt hash-ref: no value found for key: 1128 Blake will see if this is a bug fixed in our local changes or something else he should fix and he'll send you the decompiled result in either case. Jay so it's hard to tell exactly what's happening. -- sam th sa...@ccs.neu.edu _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://teammccarthy.org/jay The glory of God is Intelligence - DC 93 _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] futures waiting for scheme_make_envunbox
At Wed, 25 Aug 2010 08:41:04 -0600, Jay McCarthy wrote: Unfortunately, trying to decompile this file produces an error in the decompiler: [sa...@punge:~/tmp plt] raco decompile mandelbrot.rkt hash-ref: no value found for key: 1128 Blake will see if this is a bug fixed in our local changes or something else he should fix and he'll send you the decompiled result in either case. The problem is that we changed the bytecode compiler to allow primitives from the `#%futures' internal module to be literals (which is a step toward allowing them to be inlined by the JIT), and we forgot to tell the decompiler. The repair (now pushed) is to add '#%futures to the set of modules consulted to build the `primitives' table in `compiler/decompile'. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
Re: [racket-dev] futures waiting for scheme_make_envunbox
At Wed, 25 Aug 2010 08:17:32 -0600, Matthew Flatt wrote: There's a `set!' implicit in the `letrec' that is implicit in the use of internal definitions. Maybe the Typed Racket optimizations confuse the compiler so that it doesn't see how to convert the `let' into a `letrec'. One requirement for converting a `letrec' to a `let' is that the right-hand side can't capture the current continuation and invoke it multiple times, because continuations can expose the different times at which `let' and `letrec' allocate locations for their bindings. That's the part of the optimizer that was confused by the use of unsafe operations. Unsafe operations by themselves aren't confusing, but the optimizer also tentatively rotates arguments between the unsafe call and a surrounding `let' to work toward a particular combination that the JIT prefers. The extra `let' layer (which goes away in the end, in this case) confused the optimizer's no-`call/cc' test. The solution was to improve the no-`call/cc' test. _ For list-related administrative tasks: http://lists.racket-lang.org/listinfo/dev
