Futures: Fine Grained Parallelism in PLT

We're 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:


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/future)
(define (loop) (loop))
 (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).


matthias said...

Why is the touch explicit?

Why don't you use future-strict primitives to force future values?

Robby said...

One could build another layer on top of this one to do things like that (and perhaps we should not have taken over the names 'future' and 'touch' and let a library like that have them).

touch is explicit so that the runtime system primitives that depend on a particular context are well-defined (eg, exception handlers and continuation marks).

Robert said...

Will never versions have it enabled by default for the OSX package?

Robby said...

Eventually, yes. But it is easy to build under mac os x. Just make sure you have the developer tool installed and then it is only a few simple commands in a Terminal window.

Robert said...

Does that "mess up" anything with the packaged installation?

Robby said...

No. You can have as many versions as you want, completely separate. (Double clicking in the finder will always choose one of the open drschemes; I haven't figured out what the OS does when none of them are open.)

griffinish said...

It seems to me that delay/thread in scheme/promise has an analogous existing interface to a later forced-touched promise-future. Outside the very important and appreciated implementation difference of having multiple CPUs, where does the analogy fall short enough to require a different set of functions?

Robby said...

Well, parallelism is an important difference, of course (enough that warrants its own, separate api so programmers know what they are getting), but another difference is that with promises the computation won't get "frozen" in the way that futures can get frozen.