[gambit-list] Marc what's the rationale for "--enable-multiple-threaded-vms --enable-smp"?

Marc Feeley feeley at iro.umontreal.ca
Wed Mar 18 09:22:52 EDT 2020


> On Mar 17, 2020, at 8:51 PM, Adam <adam.mlmb at gmail.com> wrote:
> 
> On Wed, 18 Mar 2020 at 00:05, Marc Feeley <feeley at iro.umontreal.ca> wrote:
> 
> > On Mar 17, 2020, at 10:42 AM, Adam <adam.mlmb at gmail.com> wrote:
> > 
> > Hi Marc,
> > 
> > Small thing, just curious, I think also this may have been clarified in some mail thread I have somewhere but I can't find it now:
> > 
> > What is the rationale for "--enable-multiple-threaded-vms --enable-smp" to be the enabling arguments for SMP?
> > 
> > Neither "--enable-multiple-threaded-vms" nor "--enable-smp" individually will do it.
> 
> To address parallelism, Gambit's Virtual Machine (VM) is organised hierarchically into N “processors” per VM.  Each Gambit “processor” can execute Scheme code independently from other “processors”.  When running on a typical OS a “processor” is an OS level thread.  If Gambit was running on bare metal then a “processor” would be a physical core of the CPU.
> 
> Having multiple processors is useful to run Scheme threads in parallel and also to perform garbage-collection faster (using parallelism to shorten the GC pause time).
> 
> Gambit has 2 thread schedulers that can be configured.
> 
> The non-SMP scheduler (which is the default) is the most mature and supports priority inheritance.  However it multiplexes all the Scheme threads on just one processor, so it doesn’t take advantage of any hardware parallelism to accelerate the execution of the Scheme threads.
> 
> The SMP scheduler (enabled with --enable-smp) is less stable and does not support priority inheritance.  On the plus side, it multiplexes the Scheme threads on all the processors and processors can steal work (runnable Scheme threads) from other processors to balance the load.
> 
> With the --disable-multiple-threaded-vms flag (which is currently the default) the number of processors used by the Gambit VM is stuck to 1.  With the --enable-multiple-threaded-vms flag the number of processors can be greater than 1 (and on typical machines it will be).  Note that you could enable multiple threaded vms and still have a number of processors equal to 1 (e.g. on a single-core machine, or using the -:p1 runtime option).
> 
> With a single processor it is possible to use the SMP scheduler (mainly for testing the scheduler or the program).  With multiple processors it is possible to use the non-SMP scheduler (if you want more stability and faster GCs).
> 
> So as you see the two flags don’t have to be tied together in any way, and it gives more configuration freedom.
> 
> Marc
> 
> Interesting.
> 
> Are you saying that "--enable-multiple-threaded-vms" enables the multiprocessor heap and garbage collector?

Yes.

> 
> So "--enable-multiple-threaded-vms --disable-smp" is a Gambit that does not work steal between processors.

Correct.

> 
> But, it does share between processors one and the same heap and globals and state variables and such in the Gambit runtime environment. (This is in contrast with "--enable-multiple-vms", which does does not do that.)

Yes all data is in the same address space and that’s how the parallel GC works (all GC threads work on the same shared memory).

The flag --enable-multiple-vms allows multiple Gambit VMs in the same OS process.  Each VM has its own heap independent from other VMs and passing references from one heap to the other is not allowed.  So conceptually it is like independent processes (in terms of restrictions) but it is implemented in the same address space (so at the lowest implementation level it is technically possible to share data).  Note that --enable-multiple-vms is still experimental.

> 
> Did I get it right?
> 
> Will "--disable-multiple-threaded-vms --enable-smp" produce a technically broken Gambit?

I haven’t tried but I see no reason why it shouldn’t work (and if there’s an issue it is certainly minor).  As I said the two aspects are independent.

Marc





More information about the Gambit-list mailing list