<div dir="ltr">Hi Marc,<div><br></div><div>Aha - so - the garbage collector can run in parallell as of today.</div><div><br></div><div>Here are some more in depth questions (also hopefully more in line with your terminology):</div><div><br></div><div><br></div><div><div>Can objects/heap be shared between (processors in different) VM:s?</div></div><div><br></div><div><br></div><div>How far has the work on multiple processors in one VM (--enable-multiple-threaded-vms) gone? Specifically:</div><div><br></div><div>Can different processors which are running in one VM, share heap/objects reliably?</div><div><div class="gmail_extra"><br></div><div class="gmail_extra">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)?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Do routines to allocate/launch and stop/collect/deallocate (more) processors in one VM exist & work reliably?</div><div class="gmail_extra"><div><br></div><div>Do routines to send messages between multiple processors in one VM exist & work reliably?</div><div><br></div><div>Do routines to facilitate work stealing between multiple processors in one VM exist & work reliably?</div><div><br></div><div><br></div><div>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?</div><div><br></div><div>Also given common sense testing, can the main branch be counted as reliable?</div><div><br></div><div><br></div><div>When in the future do you think the runtime including IO will be proofed for use across multiple processors in one VM?</div><div><br></div><div>Thanks and best regards,</div><div>Adam</div><div><br></div><div class="gmail_quote">2017-08-15 22:24 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<span class="gmail-HOEnZb"><font color="#888888"><br>
Marc<br>
</font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
<br>
> On Aug 11, 2017, at 7:13 AM, Adam <<a href="mailto:adam.mlmb@gmail.com">adam.mlmb@gmail.com</a>> wrote:<br>
><br>
> Hi Marc,<br>
><br>
> 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.<br>
><br>
> Is this a correct understanding, and, is there any practical use of the SMP currently?<br>
><br>
> 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?<br>
><br>
> Adam<br>
<br>
</div></div></blockquote></div><br></div></div></div>