[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Z asked me for this info about Lisp's memory usage so that he could
predict the impact of 64 bit pointers. I'm sending this to the group also
because I though some of you might be interested in what the actual impact
The bottom line is that 9,318,852 bytes of the core would double in size,
and that 18,044,548 bytes of the core would stay the same. Or 27,363,400
bytes would increase to 36,682,252 bytes (1.34x).
But this is a worst case. In actuality, if your pointers were 64 bits, you
would change the object representations, not just enlarge them. For
example, single-floats could be immediate objects (all 70 of them!), and
some integers that are currently bignums would be fixnums. More
significantly, vectors could have the length encoded in the header instead
as an additional word, which would save one word per vector (for a savings
of 1,109,992 bytes).
I tacked the raw data onto the end of this message, including a full type
breakdown. (I wonder where the hell that one complex number is coming
ps: I assumed that object headers would have to increase to 64 bits. For
descriptor objects you either extend the header or waste the other 32 bits,
cause all the other slots have to be 64 bits. For non-descriptor objects,
you could still get by with a 32 bit header, but I assumed that you would
want the header size the same, so that descriptor vectors and
non-descriptor vectors would look the same. I guess you could use a 64 bit
header for descriptor objects and vectors, and a 32 bit header for
non-descriptor non-vector objects. But the only objects that would benefit
from that are the 1036 bignums. That would save you 4144 bytes. Doesn't
seem worth it.
pps: Rob, I finished fixing room.lisp to know about the new structure
2,192,299 words allocated for descriptor objects.
18,044,548 bytes data/137,414 words header for non-descriptor objects.
2,074,497 words allocated for descriptor objects.
18,068,068 bytes data/139,898 words header for non-descriptor objects.
user> (sparc::memory-usage :count-spaces t)
Summary of spaces: static dynamic read-only
12,574,096 bytes, 9,897 objects, 100% read-only, 0% dynamic.
4,109,832 bytes, 52,821 objects, 100% read-only, 0% dynamic.
3,034,080 bytes, 66,806 objects, 57% read-only, 12% dynamic, 31% static.
2,048,440 bytes, 57,208 objects, 99% read-only, 1% dynamic.
1,575,704 bytes, 22,988 objects, 28% read-only, 3% dynamic, 69% static.
1,352,872 bytes, 169,109 objects, 34% read-only, 12% dynamic, 54% static.
812,896 bytes, 25,403 objects, 2% dynamic, 98% static.
275,696 bytes, 18,329 objects, 67% read-only, 33% dynamic.
165,840 bytes, 20,730 objects, 0% read-only, 100% dynamic.
91,864 bytes, 5,630 objects, 99% read-only, 1% dynamic.
89,440 bytes, 5,590 objects, 100% read-only, 0% dynamic.
79,144 bytes, 1,631 objects, 100% read-only, 0% dynamic.
50,512 bytes, 3,157 objects, 100% read-only, 0% dynamic.
14,152 bytes, 1,036 objects, 90% read-only, 10% dynamic.
10,000 bytes, 312 objects, 1% read-only, 1% dynamic, 99% static.
8,360 bytes, 13 objects, 100% read-only.
976 bytes, 122 objects, 11% dynamic, 89% static.
688 bytes, 43 objects, 100% read-only.
560 bytes, 70 objects, 100% read-only.
144 bytes, 9 objects, 89% read-only, 11% static.
16 bytes, 1 object, 100% read-only.
26,295,312 bytes, 460,905 objects.