<div dir="ltr">Wow. This is a big day. Thank you.<div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-08-21 21:13 GMT+08:00 Marc Feeley <span dir="ltr"><<a href="mailto:feeley@iro.umontreal.ca" target="_blank">feeley@iro.umontreal.ca</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Aug 21, 2017, at 8:11 AM, Adam <<a href="mailto:adam.mlmb@gmail.com">adam.mlmb@gmail.com</a>> wrote:<br>
><br>
> Hi Marc,<br>
><br>
</span><span class="">> Aha - so - the garbage collector can run in parallell as of today.<br>
><br>
> Here are some more in depth questions (also hopefully more in line with your terminology):<br>
><br>
><br>
> Can objects/heap be shared between (processors in different) VM:s?<br>
><br>
<br>
</span>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.<br>
<span class=""><br>
><br>
> How far has the work on multiple processors in one VM (--enable-multiple-threaded-<wbr>vms) gone? Specifically:<br>
><br>
> Can different processors which are running in one VM, share heap/objects reliably?<br>
<br>
</span>Yes this is reliable.  In other words, the GC is reliable on multiple threaded VMs.<br>
<span class=""><br>
><br>
> 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)?<br>
<br>
</span>Yes.  The subset is very large… mainly stay away from thread priorities… for now.<br>
<span class=""><br>
><br>
> Do routines to allocate/launch and stop/collect/deallocate (more) processors in one VM exist & work reliably?<br>
<br>
</span>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.<br>
<br>
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…<br>
<span class=""><br>
><br>
> Do routines to send messages between multiple processors in one VM exist & work reliably?<br>
<br>
</span>Yes.  Here’s a simple example with thread-send :<br>
<br>
(declare (standard-bindings) (block))<br>
<br>
(define (busy-sleep n)<br>
  (if (> n 0)<br>
      (busy-sleep (- n 1))<br>
      #f))<br>
<br>
(define (short-delay)<br>
  (busy-sleep 100000)) ;; about 100 microseconds<br>
<br>
(define (go n)<br>
<br>
  (define (ring next-thread)<br>
    (let loop ()<br>
      (let ((msg (thread-receive)))<br>
        (thread-send next-thread (- msg 1))<br>
        (short-delay)<br>
        (if (> msg 0)<br>
            (loop)))))<br>
<br>
  (letrec ((t1 (make-thread (lambda () (ring t2))))<br>
           (t2 (make-thread (lambda () (ring t3))))<br>
           (t3 (make-thread (lambda () (ring t4))))<br>
           (t4 (make-thread (lambda () (ring t1)))))<br>
<br>
    (for-each thread-start! (list t1 t2 t3 t4))<br>
<br>
    (thread-send t1 n)<br>
<br>
    (for-each thread-join! (list t1 t2 t3 t4))))<br>
<br>
(time (go 1000000))<br>
<br>
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.<br>
<br>
Other interprocessor communication mechanisms also work (mutexes, condition variables, etc).<br>
<span class=""><br>
><br>
> Do routines to facilitate work stealing between multiple processors in one VM exist & work reliably?<br>
><br>
<br>
</span>Yes work stealing is implemented.<br>
<span class=""><br>
><br>
> 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?<br>
<br>
</span>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-<wbr>vms.<br>
<br>
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-<wbr>vms in their build process.<br>
<span class=""><br>
><br>
> Also given common sense testing, can the main branch be counted as reliable?<br>
><br>
<br>
</span>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.<br>
<span class=""><br>
><br>
> When in the future do you think the runtime including IO will be proofed for use across multiple processors in one VM?<br>
<br>
</span>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.<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Thanks and best regards,<br>
> Adam<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">Marc<br>
<br>
</font></span><br><br>
<br>
<br></blockquote></div><br></div>