[gambit-list] SMP works up to what point in GSC, any practical use possible currently?

[Adam]

Hi Marc,

When starting GSC, spawning more GVM:s will work (= a part of SMP), the
heap will work across more GVM:s (= another part of SMP), however the IO
subsystem is not SMP:ified at all so as soon as you hit the REPL things
will break bad.

Is this a correct understanding, and, is there any practical use of the SMP
currently?

Like, some subset of the runtime that actually is SMP-proof (e.g. all
except for IO) so you could use secondary GVM:s for computation in green
threads and talk to them via some SMP-proof messaging primitives?

Adam

[Marc Feeley]

Not sure what you mean by “spawning more GVMs”… Gambit’s model for concurrency within a single OS process is a single VM or multiple VMs, and within each VM there is a single “processor” or multiple “processors” (each processor is actually an OS thread). These can be enabled with the --enable-multiple-vms and --enable-multiple-threaded-vms flags respectively. Both of these flags are still experimental and work remains to be done (in the “smp” branch) to get it working smoothly. However --enable-multiple-threaded-vms in the master branch will allow the garbage collector to run in parallel, with very good speedups on large heaps so that is useful right now even if Scheme threads are still green.

Marc

Post by Adam
Hi Marc,
When starting GSC, spawning more GVM:s will work (= a part of SMP), the heap will work across more GVM:s (= another part of SMP), however the IO subsystem is not SMP:ified at all so as soon as you hit the REPL things will break bad.
Is this a correct understanding, and, is there any practical use of the SMP currently?
Like, some subset of the runtime that actually is SMP-proof (e.g. all except for IO) so you could use secondary GVM:s for computation in green threads and talk to them via some SMP-proof messaging primitives?
Adam

[Adam]

Hi Marc,

Aha - so - the garbage collector can run in parallell as of today.

Here are some more in depth questions (also hopefully more in line with
your terminology):


Can objects/heap be shared between (processors in different) VM:s?


How far has the work on multiple processors in one VM
(--enable-multiple-threaded-vms) gone? Specifically:

Can different processors which are running in one VM, share heap/objects
reliably?

Can multiple processors which are running in one VM execute [code] in
parallel reliably, presuming all but the root/first processor only utilizes
some given subset of the runtime (e.g. math and list processing is fine but
no IO as the IO not is multiprocessor-safe yet)?

Do routines to allocate/launch and stop/collect/deallocate (more)
processors in one VM exist & work reliably?

Do routines to send messages between multiple processors in one VM exist &
work reliably?

Do routines to facilitate work stealing between multiple processors in one
VM exist & work reliably?


I presume all the above is in the smp branch. Given some common sense
testing for a particular git commit, can the smp branch be counted as
reliable?

Also given common sense testing, can the main branch be counted as reliable?


When in the future do you think the runtime including IO will be proofed
for use across multiple processors in one VM?

Thanks and best regards,
Adam

Not sure what you mean by “spawning more GVMs”
 Gambit’s model for
concurrency within a single OS process is a single VM or multiple VMs, and
within each VM there is a single “processor” or multiple “processors” (each
processor is actually an OS thread). These can be enabled with the
--enable-multiple-vms and --enable-multiple-threaded-vms flags
respectively. Both of these flags are still experimental and work remains
to be done (in the “smp” branch) to get it working smoothly. However
--enable-multiple-threaded-vms in the master branch will allow the garbage
collector to run in parallel, with very good speedups on large heaps so
that is useful right now even if Scheme threads are still green.
Marc

Post by Adam
Hi Marc,
When starting GSC, spawning more GVM:s will work (= a part of SMP), the

heap will work across more GVM:s (= another part of SMP), however the IO
subsystem is not SMP:ified at all so as soon as you hit the REPL things
will break bad.

Post by Adam
Is this a correct understanding, and, is there any practical use of the

SMP currently?

Post by Adam
Like, some subset of the runtime that actually is SMP-proof (e.g. all

except for IO) so you could use secondary GVM:s for computation in green
threads and talk to them via some SMP-proof messaging primitives?

Post by Adam
Adam

[Marc Feeley]

Post by Adam
Hi Marc,
Aha - so - the garbage collector can run in parallell as of today.
Can objects/heap be shared between (processors in different) VM:s?

No, by design. Each VM has its independent GC and runtime system. Very few things are shared
 the heartbeat timer (this is an OS constraint) and symbols.

Post by Adam
Can different processors which are running in one VM, share heap/objects reliably?

Yes this is reliable. In other words, the GC is reliable on multiple threaded VMs.

Post by Adam
Can multiple processors which are running in one VM execute [code] in parallel reliably, presuming all but the root/first processor only utilizes some given subset of the runtime (e.g. math and list processing is fine but no IO as the IO not is multiprocessor-safe yet)?

Yes. The subset is very large
 mainly stay away from thread priorities
 for now.

Post by Adam
Do routines to allocate/launch and stop/collect/deallocate (more) processors in one VM exist & work reliably?

Yes. The only part that is not thoroughly tested is the handling of errors when the VM is resized (i.e. resizing the VM from 1 to 8 processors, what happens when the OS fails to allocate the OS thread for processor #4?). The handling code is there to detect this but it isn’t graceful (fatal error) and it hasn’t been tested much.

The call (##current-vm-resize ##startup-processor! N) where N is the new size will do this, but it is an internal function for implementing the VM that shoudn’t be used if you don’t know what you are doing


Post by Adam
Do routines to send messages between multiple processors in one VM exist & work reliably?

Yes. Here’s a simple example with thread-send :

(declare (standard-bindings) (block))

(define (busy-sleep n)
(if (> n 0)
(busy-sleep (- n 1))
#f))

(define (short-delay)
(busy-sleep 100000)) ;; about 100 microseconds

(define (go n)

(define (ring next-thread)
(let loop ()
(let ((msg (thread-receive)))
(thread-send next-thread (- msg 1))
(short-delay)
(if (> msg 0)
(loop)))))

(letrec ((t1 (make-thread (lambda () (ring t2))))
(t2 (make-thread (lambda () (ring t3))))
(t3 (make-thread (lambda () (ring t4))))
(t4 (make-thread (lambda () (ring t1)))))

(for-each thread-start! (list t1 t2 t3 t4))

(thread-send t1 n)

(for-each thread-join! (list t1 t2 t3 t4))))

(time (go 1000000))

When this is run in a 4 processor VM, all the processors are kept working at a high percentage (~ 80%), so the speedup over a 1 processor VM is close to 4. See the parallelism profile generated by xactlog below.

Other interprocessor communication mechanisms also work (mutexes, condition variables, etc).

Post by Adam
Do routines to facilitate work stealing between multiple processors in one VM exist & work reliably?

Yes work stealing is implemented.

Post by Adam
I presume all the above is in the smp branch. Given some common sense testing for a particular git commit, can the smp branch be counted as reliable?

The SMP branch was combined with the master branch yesterday. The configure option --enable-smp will enable the SMP Scheme thread scheduler (but you have to “make;make bootclean;make” to activate it). You also need --enable-multiple-threaded-vms.

While I’m on this subject, --enable-multiple-threaded-vms will become the new default after the next release. So those who prefer to not use the parallel GC should start adding --disable-multiple-threaded-vms in their build process.

Post by Adam
Also given common sense testing, can the main branch be counted as reliable?

The master branch contains the latest development patches, so it should not be considered maximally reliable. It happens on occasion that a patch breaks some existing infrequently used feature. If you want the highest reliability use a release.

Post by Adam
When in the future do you think the runtime including IO will be proofed for use across multiple processors in one VM?

On my TODO over the next 6 months. The SMP Scheme thread scheduler is already in good shape. The time consuming part (yet to be done) is implementing thread priorities and fine tuning and testing the runtime system.

Post by Adam
Thanks and best regards,
Adam

Marc

[Adam]

Wow. This is a big day. Thank you.

Post by Marc Feeley

Post by Adam
Hi Marc,
Aha - so - the garbage collector can run in parallell as of today.
Here are some more in depth questions (also hopefully more in line with
Can objects/heap be shared between (processors in different) VM:s?

No, by design. Each VM has its independent GC and runtime system. Very
few things are shared
 the heartbeat timer (this is an OS constraint) and
symbols.

Post by Adam
How far has the work on multiple processors in one VM
Can different processors which are running in one VM, share heap/objects

reliably?
Yes this is reliable. In other words, the GC is reliable on multiple threaded VMs.

Post by Adam
Can multiple processors which are running in one VM execute [code] in

parallel reliably, presuming all but the root/first processor only utilizes
some given subset of the runtime (e.g. math and list processing is fine but
no IO as the IO not is multiprocessor-safe yet)?
Yes. The subset is very large
 mainly stay away from thread priorities
 for now.

Post by Adam
Do routines to allocate/launch and stop/collect/deallocate (more)

processors in one VM exist & work reliably?
Yes. The only part that is not thoroughly tested is the handling of errors
when the VM is resized (i.e. resizing the VM from 1 to 8 processors, what
happens when the OS fails to allocate the OS thread for processor #4?).
The handling code is there to detect this but it isn’t graceful (fatal
error) and it hasn’t been tested much.
The call (##current-vm-resize ##startup-processor! N) where N is the new
size will do this, but it is an internal function for implementing the VM
that shoudn’t be used if you don’t know what you are doing


Post by Adam
Do routines to send messages between multiple processors in one VM exist

& work reliably?
(declare (standard-bindings) (block))
(define (busy-sleep n)
(if (> n 0)
(busy-sleep (- n 1))
#f))
(define (short-delay)
(busy-sleep 100000)) ;; about 100 microseconds
(define (go n)
(define (ring next-thread)
(let loop ()
(let ((msg (thread-receive)))
(thread-send next-thread (- msg 1))
(short-delay)
(if (> msg 0)
(loop)))))
(letrec ((t1 (make-thread (lambda () (ring t2))))
(t2 (make-thread (lambda () (ring t3))))
(t3 (make-thread (lambda () (ring t4))))
(t4 (make-thread (lambda () (ring t1)))))
(for-each thread-start! (list t1 t2 t3 t4))
(thread-send t1 n)
(for-each thread-join! (list t1 t2 t3 t4))))
(time (go 1000000))
When this is run in a 4 processor VM, all the processors are kept working
at a high percentage (~ 80%), so the speedup over a 1 processor VM is close
to 4. See the parallelism profile generated by xactlog below.
Other interprocessor communication mechanisms also work (mutexes,
condition variables, etc).

Post by Adam
Do routines to facilitate work stealing between multiple processors in

one VM exist & work reliably?
Yes work stealing is implemented.

Post by Adam
I presume all the above is in the smp branch. Given some common sense

testing for a particular git commit, can the smp branch be counted as
reliable?
The SMP branch was combined with the master branch yesterday. The
configure option --enable-smp will enable the SMP Scheme thread scheduler
(but you have to “make;make bootclean;make” to activate it). You also need
--enable-multiple-threaded-vms.
While I’m on this subject, --enable-multiple-threaded-vms will become the
new default after the next release. So those who prefer to not use the
parallel GC should start adding --disable-multiple-threaded-vms in their
build process.

Post by Adam
Also given common sense testing, can the main branch be counted as

reliable?
The master branch contains the latest development patches, so it should
not be considered maximally reliable. It happens on occasion that a patch
breaks some existing infrequently used feature. If you want the highest
reliability use a release.

Post by Adam
When in the future do you think the runtime including IO will be proofed

for use across multiple processors in one VM?
On my TODO over the next 6 months. The SMP Scheme thread scheduler is
already in good shape. The time consuming part (yet to be done) is
implementing thread priorities and fine tuning and testing the runtime
system.

Post by Adam
Thanks and best regards,
Adam

Marc