[Openmcl-devel] memory

[Tim Bradshaw]

On 14 Apr 2010, at 22:50, Toomas Altosaar wrote:

> For example, the same as above: take the case where you wish to
> mirror all the non-LISP specific implementation data in your instance
> through an FFI to and from a framework. This version will give you a
> lower bound as to how much memory requires reserving.
>
> Another example: let's say you wish to estimate how much
> memory/bandwidth/time is required for the serialization of a compound
> Lisp object between two (LISP) nodes located in remote locations on
> some network, assuming already that the other node is running the
> same version and has the same class definitions on hand. Without
> knowing the RAW number of bytes you will not be able to make an
> estimate.
>
>> Perhaps your objection is that this thing should not be called sizeof
>> because it's too reminiscent of the C function.
>
> I would object as well; it is much easier to expect a similarly named
> function to do the same thing across languages than to remember the
> differences.

OK, so I can see two objections here, I think:

1. You want the *name* "sizeof" to do what they would expect, from C,  
it would.  This is fine, I have no issues about what the function is  
called, and in any case "sizeof" is not a very Lispy name (size-of  
would be better).

2, But actually, as far as I can see, you don't want it to do what it  
does in C, I think.  because what it does in C, of course, is *not*  
return the raw number of bytes: it returns the number of bytes it  
would take to store an object, which (as in Lisp) is raw number of  
bytes + overhead, where C's overhead is typically padding. (This is  
why, despite the non-lispy name, I thought "sizeof" was reasonable,  
because it does the equivalent thing for Lisp that it does for C).

So, what do you want sizeof to do?  In your first example of copying  
Lisp data to some foreign language (say C), what you need to know is  
what *C's* sizeof returns for the struct you've defined in C to hold  
the data.  This is not the raw bytes, and I don't think it is easily  
derivable from them as it depends on layout (and perhaps compiler  
options - doesn't x86 support misaligned access? Do any compilers  
generate code which does this (I hope not)).

In the case where you're considering transmitting data over some  
network stream then what you want is probably the raw bytes, but this  
is not what C's sizeof tells you of course - in other words, if you  
were doing this in C, you could not use sizeof for this either, for  
non-trivial types.

So, I definitely don't think a function which returns the raw bytes  
used, without overhead, by an object should be called sizeof, because  
this might lead you to think that it would tell you, for instance, how  
much space it would take in C, which it would not do.  As far as I can  
see such a function would really only be useful for serializing data:  
maybe it should be called "serialized-size" or something.