From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: redoing SCM representation in 2.2 Date: Fri, 13 May 2011 18:08:56 -0400 Message-ID: <87ei42qmmf.fsf@netris.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1305324579 22303 80.91.229.12 (13 May 2011 22:09:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 13 May 2011 22:09:39 +0000 (UTC) Cc: guile-devel To: Andy Wingo Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat May 14 00:09:34 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QL0Y8-000468-N8 for guile-devel@m.gmane.org; Sat, 14 May 2011 00:09:32 +0200 Original-Received: from localhost ([::1]:49794 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QL0Y7-0003xz-PX for guile-devel@m.gmane.org; Fri, 13 May 2011 18:09:31 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:51033) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QL0Y6-0003xu-JY for guile-devel@gnu.org; Fri, 13 May 2011 18:09:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QL0Y5-0000PQ-Jn for guile-devel@gnu.org; Fri, 13 May 2011 18:09:30 -0400 Original-Received: from world.peace.net ([96.39.62.75]:50266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QL0Y5-0000NC-FL for guile-devel@gnu.org; Fri, 13 May 2011 18:09:29 -0400 Original-Received: from turntable.mit.edu ([18.160.0.29] helo=freedomincluded) by world.peace.net with esmtpa (Exim 4.69) (envelope-from ) id 1QL0Xl-0007xr-FM; Fri, 13 May 2011 18:09:09 -0400 Original-Received: from mhw by freedomincluded with local (Exim 4.69) (envelope-from ) id 1QL0XZ-0000w2-6F; Fri, 13 May 2011 18:08:57 -0400 In-Reply-To: (Andy Wingo's message of "Thu, 12 May 2011 12:17:56 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12488 Archived-At: Hi Andy, Andy Wingo writes: > I'm looking at new SCM representation and tagging possibilities in 2.2. > Read the whole mail please, as it's a little complicated. Unfortunately I don't have time to write a proper response right now, but on 32-bit architectures, I expect that this will nearly double the memory usage for typical programs, where pointers are by far the most common object. Let's keep in mind that on modern architectures, efficient memory usage is becoming increasingly important for good performance. It is often far more important than other optimizations. NaN-boxing is probably a somewhat more reasonable choice for Javascript implementations in web browsers for two reasons: (1) the only first-class numbers supported by Javascript are floating-point numbers, and (2) web browsers are already memory hogs, so doubling the memory used by Javascript's first-class values won't be noticed as much. > The current system has a couple of problems: > > 1) You can only tell a pair by dereferencing the pointer and checking > the cell's low bits, and then we need complicated tricks to set the > pair's bits on the value that is in the car. > > (This strategy was necessary with the old GC, but is not needed > with the BDW GC.) > > 2) You can only tell a procedure by dereferencing the pointer and > checking the cell's word. > > 3) Doubles are allocated on the heap. This is, as my grandmother > would say, turrible. Of the three problems mentioned above, I find only the third to be compelling, but still not sufficiently compelling to justify nearly doubling memory usage of typical programs. Best, Mark