Could someone please throw more light on these configure options:
--enable-multiple-vms, --enable-multiple-threaded-vms, --enable-max-processors, --enable-thread-system
What is the state of multi-processor support in gambit? Is there any sample code?
I would also like to know why `poll` is not the default select method ( or why configure options `--enable-poll` is `NO` by default).
Thanks,
--Vijay
Afficher les réponses par date
Those configure options, which are off by default, are for building a multi-processor version of Gambit.
Multi-processor support is actively being worked on and in particular, a parallel GC is being implemented. It is not currently operational, so there is no need to use those configure options at this moment.
As for poll vs. select, the default is to use select because it is both more portable and it uses a microsecond resolution timeout (poll uses a millisecond resolution timeout).
Marc
On Mar 9, 2016, at 12:26 PM, Vijay Mathew vijay.the.lisper@gmail.com wrote:
Could someone please throw more light on these configure options:
--enable-multiple-vms, --enable-multiple-threaded-vms, --enable-max-processors, --enable-thread-system
What is the state of multi-processor support in gambit? Is there any sample code?
I would also like to know why `poll` is not the default select method ( or why configure options `--enable-poll` is `NO` by default).
Thanks,
--Vijay _______________________________________________ Gambit-list mailing list Gambit-list@iro.umontreal.ca https://webmail.iro.umontreal.ca/mailman/listinfo/gambit-list
Multi-processor support is actively being worked on and in particular, a parallel GC is being implemented. It is not currently operational, so there is no need to use those configure options at this moment.
That's exciting! \o/ What approach are you following for the GC, Marc?
The parallel GC is a Cheney-style copying collector of the “work stealing” variety. Each “processor” (in reality, an OS thread) has its own set of roots (the Scheme thread it is running, its stack and registers). When the heap memory has been filled, all processors interrupt their current work to start a synchronous collection. Each processor marks its roots, and then proceeds with scanning the objects it has copied to tospace. This is done with little synchronisation with other processors. When a processor finishes scanning the objects it has copied, it steals scanning work from other processors. The GC ends when all scanning has been done.
Obviously I’m skipping all the nitty gritty details.
Marc
On Mar 10, 2016, at 12:33 PM, Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com wrote:
Multi-processor support is actively being worked on and in particular, a parallel GC is being implemented. It is not currently operational, so there is no need to use those configure options at this moment.
That's exciting! \o/ What approach are you following for the GC, Marc?
Nice, thank you Marc!
Just to draw some (preliminary) conclusions: it is also STW, and in this case you have to take care that the heaps fill their heap at similar rates, because if one fills the other threads will stop their work too. Although I guess the "work stealing" part compensates for that. Is this correct?
Are you pushing progress to Github?
On Thu, Mar 10, 2016 at 8:13 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
The parallel GC is a Cheney-style copying collector of the “work stealing” variety. Each “processor” (in reality, an OS thread) has its own set of roots (the Scheme thread it is running, its stack and registers). When the heap memory has been filled, all processors interrupt their current work to start a synchronous collection. Each processor marks its roots, and then proceeds with scanning the objects it has copied to tospace. This is done with little synchronisation with other processors. When a processor finishes scanning the objects it has copied, it steals scanning work from other processors. The GC ends when all scanning has been done.
Obviously I’m skipping all the nitty gritty details.
Marc
On Mar 10, 2016, at 12:33 PM, Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com wrote:
Multi-processor support is actively being worked on and in particular, a parallel GC is being implemented. It is not currently operational, so there is no need to use those configure options at this moment.
That's exciting! \o/ What approach are you following for the GC, Marc?
Not really… The thing is that there is one conceptual heap per VM, but the heap is composed of a bunch of sections (called msections for “movable sections”, i.e. sections containing movable objects). Each processor starts off with one msection for its heap allocations and one msection for its stack allocations, and the unused msections remaining are kept in a free list. When a processor overflows its heap, it gets the next msection from the free list and continues allocating in that msection. So it is only when the free list of msections is exhausted that the synchronous GC is started. One processor may have consumed 2 msections and the other 100, it doesn’t have to be balanced to achieve good usage of memory. The msections are small enough that the unused part within the last msection used by a processor (before a GC) will not impact performance much. Anyway, that is the theory that will have to be verified through experiments.
Marc
On Mar 10, 2016, at 5:21 PM, Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com wrote:
Nice, thank you Marc!
Just to draw some (preliminary) conclusions: it is also STW, and in this case you have to take care that the heaps fill their heap at similar rates, because if one fills the other threads will stop their work too. Although I guess the "work stealing" part compensates for that. Is this correct?
Are you pushing progress to Github?
On Thu, Mar 10, 2016 at 8:13 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
The parallel GC is a Cheney-style copying collector of the “work stealing” variety. Each “processor” (in reality, an OS thread) has its own set of roots (the Scheme thread it is running, its stack and registers). When the heap memory has been filled, all processors interrupt their current work to start a synchronous collection. Each processor marks its roots, and then proceeds with scanning the objects it has copied to tospace. This is done with little synchronisation with other processors. When a processor finishes scanning the objects it has copied, it steals scanning work from other processors. The GC ends when all scanning has been done.
Obviously I’m skipping all the nitty gritty details.
Marc
On Mar 10, 2016, at 12:33 PM, Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com wrote:
Multi-processor support is actively being worked on and in particular, a parallel GC is being implemented. It is not currently operational, so there is no need to use those configure options at this moment.
That's exciting! \o/ What approach are you following for the GC, Marc?
On Thu, Mar 10, 2016 at 11:40 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
Not really… The thing is that there is one conceptual heap per VM, but the heap is composed of a bunch of sections (called msections for “movable sections”, i.e. sections containing movable objects). Each processor starts off with one msection for its heap allocations and one msection for its stack allocations, and the unused msections remaining are kept in a free list. When a processor overflows its heap, it gets the next msection from the free list and continues allocating in that msection. So it is only when the free list of msections is exhausted that the synchronous GC is started. One processor may have consumed 2 msections and the other 100, it doesn’t have to be balanced to achieve good usage of memory. The msections are small enough that the unused part within the last msection used by a processor (before a GC) will not impact performance much. Anyway, that is the theory that will have to be verified through experiments.
Ah, I understand, makes sense. Thanks for the explanation. Out of curiosity, what lead you to choose this style of parallel GC?
Marc
On Mar 10, 2016, at 5:21 PM, Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com wrote:
Nice, thank you Marc!
Just to draw some (preliminary) conclusions: it is also STW, and in this case you have to take care that the heaps fill their heap at similar rates, because if one fills the other threads will stop their work too. Although I guess the "work stealing" part compensates for that. Is this correct?
Are you pushing progress to Github?
On Thu, Mar 10, 2016 at 8:13 PM, Marc Feeley feeley@iro.umontreal.ca wrote:
The parallel GC is a Cheney-style copying collector of the “work stealing” variety. Each “processor” (in reality, an OS thread) has its own set of roots (the Scheme thread it is running, its stack and registers). When the heap memory has been filled, all processors interrupt their current work to start a synchronous collection. Each processor marks its roots, and then proceeds with scanning the objects it has copied to tospace. This is done with little synchronisation with other processors. When a processor finishes scanning the objects it has copied, it steals scanning work from other processors. The GC ends when all scanning has been done.
Obviously I’m skipping all the nitty gritty details.
Marc
On Mar 10, 2016, at 12:33 PM, Álvaro Castro-Castilla alvaro.castro.castilla@gmail.com wrote:
Multi-processor support is actively being worked on and in particular, a parallel GC is being implemented. It is not currently operational, so there is no need to use those configure options at this moment.
That's exciting! \o/ What approach are you following for the GC, Marc?