About 'futures'

About 'futures'

[Marius Vollmer]

Hi,

what is the difference between

    (join-thread (begin-thread (foo)))

and

    (future-ref (future (foo)))

I am thinking about implementing futures as just

    (define-macro (future exp) `(begin-thread ,exp))
    (define future-ref join-thread)

Would that make sense?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: About 'futures'

[Mikael Djurfeldt]

On Tue, 08 Mar 2005 19:04:17 +0100, Marius Vollmer
<marius.vollmer@uni-dortmund.de> wrote:
> what is the difference between
> 
>     (join-thread (begin-thread (foo)))
> 
> and
> 
>     (future-ref (future (foo)))

The first construct is guaranteed to start a new OS thread with its
own, complete, dynamic context.  The indended usage pattern is an
application divided into a number of threads handling different tasks.
The implementation is optimized for the completeness of the
environment provided in the thread rather than, e.g., startup time.

The second is a lightweight mechanism intended for fast, small-scale,
parallelism, such as in the `letpar' or 'par-map' constructs which
evaluate its component expressions in parallel. The implementation is
optimized for quick start and delivery of the result rather than
providing a complete context rooted in a new OS thread. The current
implementation caches a number of "workers", so rather than spawning a
new thread, `future' simply implies signalling a condition variable.
(The current implementation is not complete since the dynamic context
is not re-initialized for each evaluation in a worker thread. In order
to complete the implementation one needs to define what "dynamic
context" includes in this case. The aim is that it should be minimal.)

> I am thinking about implementing futures as just
> 
>     (define-macro (future exp) `(begin-thread ,exp))
>     (define future-ref join-thread)
> 
> Would that make sense?

I don't think so for obvious reasons.  It would not make sense to
spawn new pthreads for the kind of usage patterns for which futures
are intended. In my opinion it's better to scrap futures entirely than
to provide the suggested implementation above.

But I would surely miss them. I have used these parallel language
constructs to make computations go faster on an SMP machine. It makes
beautiful sense when the subexpressions of a letpar are matrix
computations with operations implemented on the C level. Note also
that futures, by their nature, necessarily needs to be maintained
together with the guile-core rather than being provided by a separate
package.

M


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: About 'futures'

[Kevin Ryde]

Mikael Djurfeldt <mdjurfeldt@gmail.com> writes:
>
> The current implementation caches a number of "workers", so rather
> than spawning a new thread,

Do they get gc'ed after a while?

The relative lightness of futures probably wants mentioning in the
manual.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: About 'futures'

[Marius Vollmer]

Mikael Djurfeldt <mdjurfeldt@gmail.com> writes:

>> Would that make sense?
>
> I don't think so for obvious reasons.  It would not make sense to
> spawn new pthreads for the kind of usage patterns for which futures
> are intended. In my opinion it's better to scrap futures entirely than
> to provide the suggested implementation above.

Ok, I see.  (I have no intention to remove futures.)

I think we need to be more concrete about the pool of threads that
futures use.  It should be documented and there should be a way to
control the number of threads, for example.

(I will also try to benchmark them, but there is a bug right now that
prevents me from using a huge number of threads... (that bug is not
related to futures))

> Note also that futures, by their nature, necessarily needs to be
> maintained together with the guile-core rather than being provided
> by a separate package.

Why is that so?


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: About 'futures'

[Marius Vollmer]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> (I will also try to benchmark them, but there is a bug right now that
> prevents me from using a huge number of threads... (that bug is not
> related to futures))

Oooookaaay, after fixing a couple of nice bugs (gdb is really good
with threads these days, I hadn't expected that), I now get these
results:

$ (time (do ((i 0 (1+ i))) ((= i 100000)) (join-thread (begin-thread #t))))
clock utime stime cutime cstime gctime
21.00 18.61  2.23   0.00   0.00  12.50

$ (time (do ((i 0 (1+ i))) ((= i 100000)) (future-ref (future #t))))
clock utime stime cutime cstime gctime
10.51  9.72  0.73   0.00   0.00   7.45

So futures are clearly faster than threads (as expected).  Nice!


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: About 'futures'

[Rob Browning]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> So futures are clearly faster than threads (as expected).  Nice!

Indeed, and as I think someone may have mentioned, we definitely need
some clarification in the docs, since they don't make it clear how
futures differ from threads.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: About 'futures'

[Rob Browning]

Marius Vollmer <marius.vollmer@uni-dortmund.de> writes:

> what is the difference between
>
>     (join-thread (begin-thread (foo)))
>
> and
>
>     (future-ref (future (foo)))
>
> I am thinking about implementing futures as just
>
>     (define-macro (future exp) `(begin-thread ,exp))
>     (define future-ref join-thread)
>
> Would that make sense?

Based on what I know of the semantics of the respective operations, it
seems fine.

Though is a terminated thread very "heavy"?  i.e. is it much heavier
than a cons pair?  If so, then one optimization for futures would be
to implement them such that when the thread is finished, the thread
pointer is dropped, so that only the result remains.

One way to do that might be to represent a future as (cons thread
result-destination).  Given that, future-ref would either join-thread
or call cdr as appropriate.  Although you'd probably also need a mutex
which might obviate any potential resource savings achieved by
dropping the thread.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel

Re: About 'futures'

[Marius Vollmer]

Rob Browning <rlb@defaultvalue.org> writes:

> Though is a terminated thread very "heavy"?  i.e. is it much heavier
> than a cons pair?

Yes.  It is a scm_i_thread struct, but the OS thread has been
deallocated already.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel