guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: redoing SCM representation in 2.2


From: Mark H Weaver
Subject: Re: redoing SCM representation in 2.2
Date: Fri, 13 May 2011 18:08:56 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Hi Andy,

Andy Wingo <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]