guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Garbage collector tuning?


From: Stefan Israelsson Tampe
Subject: Re: Garbage collector tuning?
Date: Thu, 10 Sep 2015 17:51:54 +0200

Hi,

If you imagine one operation to fill in one byte, the timing for actually using the area is 0.3G operations per second so probable the allocation time is still considerable less than the overall algorithm to use all the memory. On the other hand it would be cool if we could fill in the 1M address space with special mappings and only in case of touching the actual region allocate the actual memory and perform the gc overhead via an exception mechansim.

Regards
Stefan

On Thu, Sep 10, 2015 at 3:30 PM, Ludovic Courtès <address@hidden> wrote:
Jan Wedekind <address@hidden> skribis:

> I wonder whether there is a more performant way to allocate larger
> memory blocks (e.g. 1 MByte). "gc-malloc-pointerless" seems to be much
> slower than "malloc":
>
>                                            user     system      total        real
>     Guile allocate memory              0.003780   0.000020   0.003800 (  0.003810)
>     C allocate memory                  0.000060   0.000000   0.000060 (  0.000070)

It isn’t fair to compare GC_malloc_pointerless with malloc.  Instead, it
should be compared with interleaved malloc + free sequences.

You should find more on this topic on the home page of libgc, the GC
that Guile uses: <http://www.hboehm.info/gc/>

> Is there a way to control how often the garbage collector is run?

The file doc/README.environment in libgc describes some useful
environment variables, notably these:

  GC_INITIAL_HEAP_SIZE=<bytes> -        Initial heap size in bytes.  May speed up
                                  process start-up.

  GC_MAXIMUM_HEAP_SIZE=<bytes> - Maximum collected heap size.

  GC_MARKERS=<n> - Linux w/threads and parallel marker only.  Set the number
                  of marker threads.  This is normally set to the number of
                  processors.  It is safer to adjust GC_MARKERS than GC_NPROCS,
                  since GC_MARKERS has no impact on the lock implementation.

Guile also honors the ‘GC_FREE_SPACE_DIVISOR’ environment variable.  See
the comments in gc.h for the meaning of this one.

HTH,
Ludo’.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]