From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Israelsson Tampe Newsgroups: gmane.lisp.guile.user Subject: Re: Garbage collector tuning? Date: Thu, 10 Sep 2015 17:51:54 +0200 Message-ID: References: <87fv2m5rly.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d0418268407fdc9051f6694be X-Trace: ger.gmane.org 1441900357 7789 80.91.229.3 (10 Sep 2015 15:52:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 15:52:37 +0000 (UTC) Cc: "guile-user@gnu.org" To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Sep 10 17:52:37 2015 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Za49E-0000FN-56 for guile-user@m.gmane.org; Thu, 10 Sep 2015 17:52:28 +0200 Original-Received: from localhost ([::1]:49999 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za49D-0007yJ-Ir for guile-user@m.gmane.org; Thu, 10 Sep 2015 11:52:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za494-0007xz-Ck for guile-user@gnu.org; Thu, 10 Sep 2015 11:52:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za492-0007rT-Vc for guile-user@gnu.org; Thu, 10 Sep 2015 11:52:18 -0400 Original-Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:37184) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za492-0007jh-KT; Thu, 10 Sep 2015 11:52:16 -0400 Original-Received: by wicfx3 with SMTP id fx3so28392618wic.0; Thu, 10 Sep 2015 08:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=en4vGhYKrfk2ETOwynqVd2UxFYgGeBXYT2APgQrtjHg=; b=BdWQDMCIKlDfVRWAY0CwAz4sDxka/iquZ+hIk7LSP5bQkviN+28SyD0MM23VBpivH/ 0xLiliJvVGYd4oZ3+VMUe9/WHqIK/C/YviDGMwaC37wJ/C/70d86niQEobPckAZ3SZub uM/r2ASx9GpGRu0a4K1uVcbMvx10KFNxFTaHKJWvS6HTekxDbbFnL0rpC0BODQr1oBLS HzeuxBLyKLwKiN9yoqkwrC+szo30aqTkuEl0VsdJdQ3R0oNy7kAaHVAQW+0PK5sh3bDv PwKWZznnR5qQXOMdxdLJshIc9xH7Jj9vVBATj8F9NfXqMBCYFXvkCknIf9bEZuJeQqC0 LMLw== X-Received: by 10.180.8.101 with SMTP id q5mr8004163wia.10.1441900314228; Thu, 10 Sep 2015 08:51:54 -0700 (PDT) Original-Received: by 10.28.159.141 with HTTP; Thu, 10 Sep 2015 08:51:54 -0700 (PDT) In-Reply-To: <87fv2m5rly.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::236 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:12008 Archived-At: --f46d0418268407fdc9051f6694be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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=C3=A8s wrote: > Jan Wedekind 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=E2=80=99t fair to compare GC_malloc_pointerless with malloc. Inst= ead, 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: > > > 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=3D - Initial heap size in bytes. Ma= y > speed up > process start-up. > > GC_MAXIMUM_HEAP_SIZE=3D - Maximum collected heap size. > > GC_MARKERS=3D - 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 =E2=80=98GC_FREE_SPACE_DIVISOR=E2=80=99 environment= variable. See > the comments in gc.h for the meaning of this one. > > HTH, > Ludo=E2=80=99. > > > --f46d0418268407fdc9051f6694be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

If you imagine one operation = to fill in one byte, the timing for actually using the area is 0.3G operati= ons per second so probable the allocation time is still considerable less t= han 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.

Rega= rds
Stefan

On Thu, Sep 10, 2015 at 3:30 PM, Ludovic Court=C3=A8s <ludo@gn= u.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":
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 user=C2=A0 =C2=A0 =C2=A0system=C2=A0 =C2=A0 =C2=A0 total=C2=A0 = =C2=A0 =C2=A0 =C2=A0 real
>=C2=A0 =C2=A0 =C2=A0Guile allocate memory=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 0.003780=C2=A0 =C2=A00.000020=C2=A0 =C2=A00.003800 (= =C2=A0 0.003810)
>=C2=A0 =C2=A0 =C2=A0C allocate memory=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 0.000060=C2=A0 =C2=A00.000000=C2=A0 =C2=A00.00= 0060 (=C2=A0 0.000070)

It isn=E2=80=99t fair to compare GC_malloc_pointerless with malloc.= =C2=A0 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:

=C2=A0 GC_INITIAL_HEAP_SIZE=3D<bytes> -=C2=A0 =C2=A0 =C2=A0 =C2=A0 In= itial heap size in bytes.=C2=A0 May speed up
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 process start-up.

=C2=A0 GC_MAXIMUM_HEAP_SIZE=3D<bytes> - Maximum collected heap size.<= br>
=C2=A0 GC_MARKERS=3D<n> - Linux w/threads and parallel marker only.= =C2=A0 Set the number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of marker th= reads.=C2=A0 This is normally set to the number of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 processors.= =C2=A0 It is safer to adjust GC_MARKERS than GC_NPROCS,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since GC_MAR= KERS has no impact on the lock implementation.

Guile also honors the =E2=80=98GC_FREE_SPACE_DIVISOR=E2=80=99 environment v= ariable.=C2=A0 See
the comments in gc.h for the meaning of this one.

HTH,
Ludo=E2=80=99.



--f46d0418268407fdc9051f6694be--