From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jan Wedekind Newsgroups: gmane.lisp.guile.user Subject: Re: Garbage collector tuning? Date: Thu, 10 Sep 2015 17:33:25 +0100 (BST) Message-ID: References: <87fv2m5rly.fsf@gnu.org> Reply-To: Jan Wedekind NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1213420525-1441902817=:12330" X-Trace: ger.gmane.org 1441902892 19706 80.91.229.3 (10 Sep 2015 16:34:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 16:34:52 +0000 (UTC) Cc: guile-user@gnu.org To: =?ISO-8859-15?Q?Ludovic_Court=E8s?= Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Thu Sep 10 18:34:42 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 1Za4nJ-0006q9-Lw for guile-user@m.gmane.org; Thu, 10 Sep 2015 18:33:53 +0200 Original-Received: from localhost ([::1]:50420 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za4nI-0000qe-Vx for guile-user@m.gmane.org; Thu, 10 Sep 2015 12:33:52 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za4n9-0000qS-Bc for guile-user@gnu.org; Thu, 10 Sep 2015 12:33:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Za4n4-0007VR-Su for guile-user@gnu.org; Thu, 10 Sep 2015 12:33:43 -0400 Original-Received: from basicbox4.server-home.net ([195.137.212.26]:50355) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Za4n4-0007Ug-KO; Thu, 10 Sep 2015 12:33:38 -0400 Original-Received: from wedemob (unknown [149.254.180.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by basicbox4.server-home.net (Postfix) with ESMTPSA id 115D61530669; Thu, 10 Sep 2015 18:33:36 +0200 (CEST) X-X-Sender: jan@wedemob In-Reply-To: <87fv2m5rly.fsf@gnu.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 195.137.212.26 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:12009 Archived-At: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1213420525-1441902817=:12330 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable On Thu, 10 Sep 2015, 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. In= stead, 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: Yes, I agree. The sequence malloc, free, malloc, free, ... is not a=20 representative use-pattern. However I only forced a single garbage=20 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=3D - Initial heap size in bytes. May spee= d 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 implementat= ion. > > Guile also honors the =E2=80=98GC_FREE_SPACE_DIVISOR=E2=80=99 environme= nt 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=E2=80=99. > > > --8323329-1213420525-1441902817=:12330--