From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Mikael Djurfeldt Newsgroups: gmane.lisp.guile.devel Subject: Re: lazy sweeping. Date: Mon, 29 Jul 2002 15:16:59 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <3D45404B.4010706@nada.kth.se> References: <15684.32520.154258.348830@blauw.xs4all.nl> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1027948601 10314 127.0.0.1 (29 Jul 2002 13:16:41 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 29 Jul 2002 13:16:41 +0000 (UTC) Cc: guile-devel@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17ZAO7-0002gF-00 for ; Mon, 29 Jul 2002 15:16:40 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17ZAOX-00085K-00; Mon, 29 Jul 2002 09:17:05 -0400 Original-Received: from mdj.nada.kth.se ([130.237.224.206] helo=l2) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17ZAOF-00084o-00 for ; Mon, 29 Jul 2002 09:16:47 -0400 Original-Received: from dyna228-217.nada.kth.se ([130.237.228.217] helo=nada.kth.se) by l2 with esmtp (Exim 3.22 #1 (Debian)) id 17ZAOD-0005kM-00; Mon, 29 Jul 2002 15:16:45 +0200 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020615 Debian/1.0.0-3 X-Accept-Language: en Original-To: hanwen@cs.uu.nl Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:881 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:881 Han-Wen wrote: >Here are some results of my lazy sweeping implementation: > >[...] > >The lazy sweeping approximately halves the startup time of GUILE. I >consider the old GC beat; when can we start integrating this? > Nice! However, be careful about benchmarking information. When hacking the evaluator, I've noticed performance changes up to 30% just by changing the textual order of functions within a compilation unit... > * Lazy sweeping naturally complements multi-threaded use: whenever a > thread runs out of free cells, we can simply sweep a few (say 512) > cells, and return that for private use by that thread. > [Without having studied your code:] Is it enough to lock one mutex for the joint apparatus of sweeping and marking before doing the lazy sweep in order to avoid interference between threads? (One would not want to stop all threads before sweeping 512 cells...) Best, M _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel