Marc what's the rationale for "--enable-multiple-threaded-vms --enable-smp"?
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.
I understand "--enable-smp" enables the "SMP scheduler", I presume that is the multiple processors operate concurrently and steal work from each other.
The "--enable-multiple-threaded-vms" enables the infrastructure for creating multiple processors within one GVM in the first place?
But then, "--enable-multiple-threaded-vms" only allows you to create a new processor but that one will be all separate from the first one - may that ever be useful without SMP work stealing operation?? I thought anyone who wanted to do that would go with "--enable-multiple-vms".
Today I dug out "--enable-multiple-threaded-vms --enable-smp" again from the manual. I looked at it twice going, hmm is this really correct, does this really look correct. After checking all over my email box I see your other email where you reiterate exactly this, and thus deduce, it's correct.
So just thought, why does enabling SMP require two separate ./configure arguments. Any comment would be much appreciated.
Thanks! Adam
Afficher les réponses par date
On Mar 17, 2020, at 10:42 AM, Adam adam.mlmb@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
On Wed, 18 Mar 2020 at 00:05, Marc Feeley feeley@iro.umontreal.ca wrote:
On Mar 17, 2020, at 10:42 AM, Adam adam.mlmb@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?
So "--enable-multiple-threaded-vms --disable-smp" is a Gambit that does not work steal between processors.
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.)
Did I get it right?
Will "--disable-multiple-threaded-vms --enable-smp" produce a technically broken Gambit?
On Mar 17, 2020, at 8:51 PM, Adam adam.mlmb@gmail.com wrote:
On Wed, 18 Mar 2020 at 00:05, Marc Feeley feeley@iro.umontreal.ca wrote:
On Mar 17, 2020, at 10:42 AM, Adam adam.mlmb@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
-
Adam -
Marc Feeley