thanks for the explanations. learning new things is always good.
In article <·················@arolla.idiap.ch> ···@arolla.idiap.ch (Thomas M. Breuel) writes:
--> In article <··········@info-server.bbn.com> ·····@labs-n.bbn.com writes:
--> |--> (1) struct { int x,y; } foo[N]; - +100% (4N vs. 2N words)
--> |
--> |I think you mean that there is integer packing in the foo[N] array. you
--> |are suggesting that x and y each get allocated a full word but only fill
--> |half of it. I wonder if that's true...
-->
--> No, not even close. Here is the tally for current CommonLisp
--> implementations:
[munch]
--> For large N, this is about 4N words (for small N, you have to add the
--> array header overhead).
well. it's far worse than I thought. I didn't realize that things were
this kind of loose or sloppy. I mean the compiler makes all sorts of
other assumptions I tend not to expect, why wouldn't it also do packing?
--> What you are mainly overlooking is the cost of representing something
--> as a heap allocated object vs. an object represented in place.
ok, I don't know what these things are.
--> |presumably you want to do zillions of array-like steps on the things
--> |you'd like to define this way. the byte-packing aspect just sounds like
--> |implementation detail. no reason to believe that it couldn't be done,
--> |it just hasn't BEEN done.
-->
--> That's what I have been saying: it can be done. It needs to be done.
I guess I'd agree here. this seems like a good thing
--> |think I've EVER worked with info you'd organize as an array of
--> |structures...
-->
I have worked with some moderately large arrays, though, now that i
think about it--map-related stuff. and I was doing some serious
crunching on them, too. obviously I was losing some speed...
--> Well, even structures of arrays are a problem. If we look just
--> at:
-->
--> struct { float vect1[3],vect2[3]; } foo;
-->
--> we get 6 words for C and 13 words for current Lisp implementations,
--> even when fully declared.
this sounds like packed allocation should simply become the default for
a fully specified definition. as a lot of them are not, it might not
actually come into play very often...
does a bit-array get packed?
--> Also, arrays of structures in C are often used not as such, but as
--> "pools" and "areas" for the dynamic allocation of objects to be passed
--> to other parts of the program as pointers. This results in
--> exceptionally fast allocation and deallocation and eliminates any
and is clearly the reason to do it--one malloc call gets you N
structures, and you can treat them as a resource as you need to. that
part sounds like a good idea to me.
are resources in ANSI CL? they're sufficiently useful, I think to
warrant being in there.
someone's idea of declaring some data as foreign structures in order to
get the packing is an interesting idea...has anyone done a study about
efficiency and speed?
-- clint
>>>>> "chyde" == chyde <·····@labs-n.bbn.com> writes:
chyde> are resources in ANSI CL? they're sufficiently useful, I think to warrant being in there.
Resources are not in the dpans; my portable version is in cl-lib, and in Mark K's
archive. (as resources.lisp).
ftp.cs.rochester.edu:/pub/knowledge-tools/cl-lib*.tar.gz