Re: GC thread performance

["Hans Åberg" <haberg-1@telia.com>]

> On 1 Dec 2017, at 20:49, Linas Vepstas <linasvepstas@gmail.com> wrote:
> 
> On Mon, Nov 27, 2017 at 5:44 PM, Hans Åberg <haberg-1@telia.com> wrote:
> 
>> 
>> 
>>> On 28 Nov 2017, at 00:23, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> 
>>> Hans Åberg <haberg-1@telia.com>:
>>>> I saw overhead also for the small allocations, 20-30% maybe. This is
>>>> in a program that makes a lot of allocations relative other
>>>> computations. So that made me wonder about Guile.
>> 
> 
> I cannot speak to GC, but I freuqently encounter situations in guile where
> using the parallel constructs e.g. par-for-each, end up running slower than
> the single-threaded version. For example, using 2 or 3 threads, I get a 2x
> and 3x speedup, great, but using 4x gives a slowdown, often 10x slower than
> single-threaded. I try to make sure that the insides of the loop are large
> and long-running, so that the cost of creating and scheduling threads is
> inconsequential.

In the program I tested it depends on what I run, but one pattern is that user time goes up about two times when approaching the hardware concurrency, and then stabilizes. System time jumps up thirty times when going from one to two threads, and then further doubles when approaching the hardware concurrency.

> I have not attempted to determine the cause of this, but basically, that
> entire subsystem needs a careful review and measurement.

The GC also collects outside the main thread, so if that part takes up too much system resources, the program itself might too slow down by that.