[plt-dev] Parallel Futures Release

On Dec  7, Jay McCarthy wrote:
> On Mon, Dec 7, 2009 at 4:40 PM, Robby Findler
> <robby at eecs.northwestern.edu> wrote:
> > On Mon, Dec 7, 2009 at 5:35 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> >>> > But I'm not sure why you would need a separate function for
> >>> > futures-count, unless you're intending it to be related to
> >>> > question (6) below?
> >>>
> >>> Not really -- I'm just thinking that people would want to know
> >>> whether futures are enabled, and `processor-count' is the way to
> >>> do this now.  So if that always returns the number of cores,
> >>> it's probably enough to have a function that returns whether
> >>> futures are available.
> >>
> >> This also doesn't make sense to me. When `(processor-count)'
> >> produces 1, it doesn't matter whether MzScheme was built with
> >> `--enable-futures' or not; the resulting lack of performance
> >> improvement is the same either way.
> >
> > Well, someone might build a OS-processlevel thingy that depends on
> > this, and it might be useful for places, too.
> 
> I would use it to replace a constant in DrDr.

I had a confusion with how I thought futures would work, which is
related to what I thought this function would return.  My guess was
that it returns the number of cores available for work *now*, not
counting cores that are running other futures.  For example, say that
I need to sort two lists, and that `sort' itself is parallelized to
use available cores.  If my code looks like:

  (let* ([f1 (future (lambda () (sort l1)))]
         [f2 (future (lambda () (sort l2)))]
         [l1 (touch f1)]
         [l2 (touch f2)])
    ...)

then (I thought) the `processor-count' function would return half of
the number of cores I actually have, so each sort has it's own share
of total cpu power.  (In other words, I thought that a result of 1 is
a natural way to restrict code to being sequential when futures are
not supported or when you're "out of cores".)

One comment on the docs: I think that the global nature of futures
should be said very explicitly at the top.  Right now, it's only an
implication of a weak side comment: you need to deduce that from the
fact that `future' is "considered" unsafe.

So given that futures don't compose, I can see how that always returns
the real number of cores, and that's exactly what Jay implemented as a
constand, and I implemented with grepping "/proc/cpuinfo".  Because of
this, I think that making it work the same in non-future-enabled
builds is also useful, with another way to know if they are enabled or
not.

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!