Garbage collector tuning?

Garbage collector tuning?

[Jan Wedekind]

Hi,
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)

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

Thanks
Jan

[1] https://github.com/wedesoft/aiscm/blob/master/bench/bench.scm
[2] https://github.com/wedesoft/aiscm/blob/master/bench/cbench.c

Re: Garbage collector tuning?

[Ludovic Courtès]

Jan Wedekind <jan@wedesoft.de> 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’.

Re: Garbage collector tuning?

[Stefan Israelsson Tampe]

[-- Attachment #1: Type: text/plain, Size: 2228 bytes --]

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 <ludo@gnu.org> wrote:

> Jan Wedekind <jan@wedesoft.de> 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’.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2977 bytes --]

Re: Garbage collector tuning?

[Jan Wedekind]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2797 bytes --]

On Thu, 10 Sep 2015, Ludovic Courtès wrote:
> Jan Wedekind <jan@wedesoft.de> 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/>

Yes, I agree. The sequence malloc, free, malloc, free, ... is not a 
representative use-pattern. However I only forced a single garbage 
collector run for a 1000 tests.
The full benchmark is here by the way:

                                            user     system      total        real
     Guile GOOPS method dispatch        0.000060   0.000000   0.000060 (  0.000050)
     Guile make empty sequence          0.000690   0.000000   0.000690 (  0.000700)
     Guile allocate memory              0.003760   0.000020   0.003780 (  0.003800)
     Guile negate empty sequence        0.003500   0.000080   0.003580 (  0.003580)
     Guile make sequence                0.002620   0.000020   0.002640 (  0.002660)
     Guile negate sequence              0.006980   0.000030   0.007010 (  0.007030)
     C allocate memory                  0.000060   0.000000   0.000060 (  0.000070)
     C negate empty sequence            0.000050   0.000000   0.000050 (  0.000040)
     C negate sequence                  0.000720   0.000000   0.000720 (  0.000720)


>> 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.

Ok, I'll play around with it. Thanks for the information.

>
> HTH,
> Ludo’.
>
>
>

Re: Garbage collector tuning?

[Jan Wedekind]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2051 bytes --]

On Thu, 10 Sep 2015, Ludovic Courtès wrote:
>  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’.
Hi Ludovic,
Increasing the initial heap size already improves the performance a lot:

     $ make bench
     ...
     make[1]: Entering directory '/home/jan/test/aiscm/bench'
     LD_LIBRARY_PATH=../aiscm/.libs:../bench/.libs:/usr/local/lib GC_INITIAL_HEAP_SIZE=1G GC_USE_ENTIRE_HEAP=Y /usr/bin/guile --no-auto-compile -L .. bench.scm
                                            user     system      total        real
     Guile GOOPS method dispatch        0.000110   0.000000   0.000110 (  0.000100)
     Guile make empty sequence          0.000640   0.000000   0.000640 (  0.000640)
     Guile allocate memory              0.000210   0.000000   0.000210 (  0.000210)
     Guile negate empty sequence        0.002950   0.000080   0.003030 (  0.003020)
     Guile make sequence                0.000740   0.000000   0.000740 (  0.000740)
     Guile negate sequence              0.003960   0.000490   0.004450 (  0.004460)
     C allocate memory                  0.000080   0.000000   0.000080 (  0.000070)
     C negate empty sequence            0.000050   0.000000   0.000050 (  0.000060)
     C negate sequence                  0.000740   0.000000   0.000740 (  0.000740)
     make[1]: Leaving directory '/home/jan/test/aiscm/bench'

I'll try to understand the free space divisor later.
Many thanks

Jan

Re: Garbage collector tuning?

[David Pirotte]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

Jan,

>      make[1]: Entering directory '/home/jan/test/aiscm/bench'
>      LD_LIBRARY_PATH=../aiscm/.libs:../bench/.libs:/usr/local/lib
>	GC_INITIAL_HEAP_SIZE=1G GC_USE_ENTIRE_HEAP=Y /usr/bin/guile
>	--no-auto-compile -L .. bench.scm user

--no-auto-compile ? 

this option is ok for scripts which does nothing but setting %load-path and/or
importing compiled modules and launch an application, for example, but to run a
benchmark I definitely would organize things so the benchmark module is compiled.

Cheers,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: Garbage collector tuning?

[Jan Wedekind]

On Thu, 10 Sep 2015, David Pirotte wrote:

> Jan,
>
>>      make[1]: Entering directory '/home/jan/test/aiscm/bench'
>>      LD_LIBRARY_PATH=../aiscm/.libs:../bench/.libs:/usr/local/lib
>> 	GC_INITIAL_HEAP_SIZE=1G GC_USE_ENTIRE_HEAP=Y /usr/bin/guile
>> 	--no-auto-compile -L .. bench.scm user
>
> --no-auto-compile ?
>
> this option is ok for scripts which does nothing but setting %load-path and/or
> importing compiled modules and launch an application, for example, but to run a
> benchmark I definitely would organize things so the benchmark module is compiled.
>
> Cheers,
> David
>

Ok, I see. I thought that option only is about writing the bytecode to 
disk. Now the benchmark only works after doing "make install" but the 
results are better :)

     $ make bench
     LD_LIBRARY_PATH=./.libs:/usr/local/lib GC_INITIAL_HEAP_SIZE=1G GC_USE_ENTIRE_HEAP=Y /usr/bin/guile bench.scm
                                            user     system      total        real
     Guile GOOPS method dispatch        0.000040   0.000000   0.000040 (  0.000040)
     Guile make empty sequence          0.000140   0.000000   0.000140 (  0.000150)
     Guile allocate memory              0.000170   0.000010   0.000180 (  0.000170)
     Guile negate empty sequence        0.001470   0.000100   0.001570 (  0.001570)
     Guile make sequence                0.000250   0.000000   0.000250 (  0.000250)
     Guile negate sequence              0.002520   0.000870   0.003390 (  0.003400)
     C allocate memory                  0.000060   0.000000   0.000060 (  0.000060)
     C negate empty sequence            0.000030   0.000000   0.000030 (  0.000030)
     C negate sequence                  0.000700   0.000000   0.000700 (  0.000710)

Regards
Jan