Re: GC thread performance

[Hans Åberg]

> On 2 Dec 2017, at 09:50, Marko Rauhamaa <address@hidden> wrote:
> 
> Guile guarantees the consistency of the data model under all
> circumstances. Bad synchronization between threads is allowed to cause
> unspecified behavior, but it should never trigger a SIGSEGV. In
> practice, that means excessive locking: all data access needs to take
> place in a critical section.

> These and other issues with multithreading have caused many of us to
> reject multithreading as a paradigm altogether. Use event-driven
> programming for multiplexing and multiprocessing for performance.

I see the the expected behavior when turing off the GC altogether, using malloc 
and free without cleanup: I third of the time on one thread, decreasing up to 
hardware concurrency.

The Boehm GC sets a lock around all allocations and collections [1], so it 
might be such excessive locking that slows it down. That pages seems old: I 
could not see a difference when choosing the options at [2].


1. http://www.hboehm.info/gc/scale.html
2. http://www.hboehm.info/gc/simple_example.html