I think one reason that we don't have it enabled in the build by default is that having it enabled adds some performance overhead, even if you aren't using futures in your program. With futures enabled, the JIT compiler doesn't emit direct calls to unsafe primitives but instead emits calls to wrapper functions. These wrappers basically exist to check whether we're attempting to invoke function X on the right thread, and if not, signal the runtime and block. So for every primitive invocation in a program, with futures enabled, this essentially becomes two function invocations. This hurts you more on some platforms than others, IIRC. I'm not sure whose decision it is to make futures enabled by default...is this generally done by consensus? -James <div class="gmail_quote">On Mon, Dec 7, 2009 at 11:43 AM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Would you like us to run some tests on many platforms and machines? What is the strategy for enabling it by default? (If it isn't ready, then what should we do to help? If it is, then let it rip!) Jay <div><div></div><div class="h5"> On Mon, Dec 7, 2009 at 10:31 AM, James Swaine <<a href="mailto:james.swaine@gmail.com">james.swaine@gmail.com</a>> wrote: > I'm pleased to announce the initial release of parallel futures, a > construct for fine-grained parallelism in PLT. Roughly speaking, a > programmer passes a thunk to 'future' and it gets run in parallel. > That "roughly" holds a few gotchas, partly because we're just getting > started and partly due to the technique we're using. See the > documentation for more details: > > <a href="http://pre.plt-scheme.org/docs/html/futures/" target="_blank">http://pre.plt-scheme.org/docs/html/futures/</a> > > If you've got a multicore machine where you can't keep the cores busy > or your office/machine room is a bit cold, try this program: > > #lang scheme > (require scheme/futures) > (define (loop) (loop)) > (for-each > touch > (for/list ([i (in-range 0 (processor-count))]) > (future loop))) > > Note that you have to build mzscheme with futures; it isn't enabled by > default, but see the docs above for how to do that. Beyond the above, > we've also gotten a few parallel kernels going and are seeing good > scalability up to 8 cores (the biggest machine we have around for the > time being). > > Many thanks to Matthew, Robby, Kevin, and Peter Dinda, without whom this > release wouldn't have been possible. > > Feedback welcome! > > James </div></div>> _________________________________________________ > For list-related administrative tasks: > <a href="http://list.cs.brown.edu/mailman/listinfo/plt-dev" target="_blank">http://list.cs.brown.edu/mailman/listinfo/plt-dev</a> > > -- Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>> Assistant Professor / Brigham Young University <a href="http://teammccarthy.org/jay" target="_blank">http://teammccarthy.org/jay</a> "The glory of God is Intelligence" - D&C 93 </blockquote></div>