[r6rs-discuss] [Formal] SRFI-39 should be made an R6RS library

From: R. Kent Dybvig <dyb>
Date: Fri Feb 23 15:53:22 2007

> > In implementation, yes. But my thread system is based on pthreads, and
> > you'd have to have quite a few parameters to notice the difference in
> > thread-creation or memory overhead. Applications don't typically use
> > very many thread parameters in any case.
>
> It's still a problem that you pay for something even if you don't use
> it: As the number of loaded libraries that use parameters grows, so do
> all of your threads. This is probably not a problem in a system with
> (comparatively) heavyweight threads such as pthreads

Right, which was my point. While I doubt this would be a problem even
with a lightweight thread system (it hasn't been with SWL), one could use
instead a sparse representation that creates per-thread locations lazily,
which should be possible at least for the ones that have their original
values at the point where the thread is forked.

> , but it is a
> problem in systems where threads take up only a few words in the
> absence of parameters.
> (For reference, the Scheme 48 Scheme code contains 33 fluids---if
> those were parameters, they would take up 33 slots in *each* thread,
> which is significant given the lightweight nature of Scheme 48's
> threads.)

Maybe. Being skeptical, however, I installed Scheme48 on my Mac laptop
and did a couple of quick tests.

Test 1: attempt to determine the space overhead for maintaining a
length-33 parameter vector. For both tests, I ran the following
boilerplate code:

  ,open threads
  ,open spatial
  (define make-list (lambda (n x) (if (= n 0) '() (cons x (make-list (- n 1) x)))))
  (define spin1 (lambda () (let f () (f))))
  (define spin2 (lambda () (let f ((v (make-vector 33))) (f v))))
  ,collect

For both runs, collect reported 772039 words free after collection.

For run 1, I created 10 threads running spin1, which doesn't allocate a
vector:

  (map spawn (make-list 10 spin1))
  ,collect

Collect reported 766974 words free after collection, a net difference of
5065 words.

For run 2, I created 10 threads running spin2, which allocates a vector
of length 33 (per thread):

  (map spawn (make-list 10 spin2))
  ,collect

In this case, collect reported 766604 words free after collection, a net
difference of 5435 words, which is an increase in the net of 7.3% over
run2.

I ran a different test to see how the thread creation-time cost might be
affected. Again I used two runs, this time with the following boilerplate
code:

  ,open threads
  ,open spatial
  (define make-list (lambda (n x) (if (= n 0) '() (cons x (make-list (- n 1) x)))))
  (define quick1 (lambda () 0))
  (define quick2 (lambda () (make-vector 33)))

For the first run I created 1000 threads running quick1, which doesn't
allocate a vector.

  ,time (begin (map spawn (make-list 10000 quick1)) 0)

For the second run I created 1000 threads running quick2, which allocates
a vector of length 33 (per thread).

  ,time (begin (map spawn (make-list 10000 quick2)) 0)

The times reported over 10 tries of the first run ranged from .47 to .52
seconds, and for 10 tries of the second, .47 to .53 seconds. The average
times were .482 and .483 seconds respectively, or essentially the same
given the time variances.

So, while 7.3% might or might not be considered significant space
overhead, there's essentially no difference in time. Of course, with more
thread parameters, both space and time overhead would go up. It's
impossible to extrapolate from the timing numbers, but extrapolating
from the space numbers, we'd pass 100% overhead, i.e., double the space
taken up by each running thread, at about 451 thread parameters.

> (Pure deep binding doesn't have this problem.)

Deep binding has undesirable overhead of its own, as I'm sure you are
aware, i.e., reference cost proportional to the number of current dynamic
bindings.

Kent
Received on Fri Feb 23 2007 - 15:53:18 UTC