[Openmcl-devel] memory

[Toomas Altosaar]

>Message: 5
>Date: Wed, 14 Apr 2010 15:23:44 +0100
>From: Tim Bradshaw <tfb at tfeb.org>
>Subject: Re: [Openmcl-devel] memory
>To: Alexander Repenning <ralex at cs.colorado.edu>
>Cc: openmcl-devel Devel <openmcl-devel at clozure.com>
>Message-ID: <BC113436-4CA0-4C0F-9BBA-106E7425DC6F at tfeb.org>
>Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
>On 14 Apr 2010, at 14:58, Alexander Repenning wrote:
>
>>  2) sizeof as C/C++/Ojective-C inspired sizeof operator returning the 
>>  number of RAW bytes with no meta information (no headers, no tag 
>>  bits, ...) typically used to deal with FFIs. Mostly used in the 
>>  context of allocating raw memory and accessing it with (%get-
>>  byte ...) kinds of functions.This is what we need to interface with 
>>  OpenGL/ Cocoa and other APIs on Macs and PCs.
>
>How is this useful?

Let's say you want to copy some data from the Lisp to a framework 
you've written in C. For this you need to know how many 8 bit bytes 
need to be reserved on the heap. You do not want to include Lisp 
overhead.

>I want SIZEOF to tell me how many instances of an
>x I can fit in y bytes of memory, not some number which tells me
>something I can't see a use for.

Others can see a very definite use for it.

>For this version of sizeof, what would, say (sizeof (make-
>instance ...)) be useful for?

I can envision many.

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.

I don't think it should be too much of a strain on LISP users to come 
up with a more descriptive and more suitable name than what is used 
in C.

This function's operation - whatever it will be called - is 
definitely implementation and version specific.

Memory-footprint, Lisp-footprint, or something shorter and catchier?

What do other LISP implementations call it?