> On 2 Dec 2017, at 09:50, Marko Rauhamaa <ma...@pacujo.net> 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
