[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 <mflatt at 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:
> 
> [samth at 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
> samth at ccs.neu.edu
> 
> ------------------------------------------------------------------------------
> [application/octet-stream "mandelbrot.rkt"] [~/Desktop & open] [~/Temp & open]