Re: nonhomogenous structs (was: lisp performance questions and observations)

From: rif (rif_at_mit.edu)
Date: 10/26/04 

Date: 26 Oct 2004 11:20:14 -0400

Duane Rettig <duane@franz.com> writes:

[many interesting comments deleted]

> So you might read and understand this, and say "But I don't care about
> bit fields; I care about the mixture of bytes, ints, longs, floats,
> and double-floats". And if this is the case (as I suspect it is), I
> will leave it to you to guess what how I might respond to that...

Upon the first couple readings of your post, I thought that the thrust
of your argument is that there is a speed tradeoff in using less space
--- as I start to use fields that need to be bitmasked and shifted to
be extracted, I will pay a speed penalty as compared to using machine
word sized pieces. (I am certainly aware of this issue, as it has
come up for me before in the "double-float floating point operations
are often much faster than single-float, in addition to being more
precise.")

However, I am clearly still missing something, as I don't think I
understand the difference between C and asm in this context. Perhaps
you meant that in C, one might end up (naively?) using bit-field
extraction operations on fields that were already properly aligned,
which is therefore wasteful, and in assembly you'd be likely to notice
this? It seems unlikely to me that that's what you meant, but I'm not
sure what you did mean.

In my application, all the fields are actually integers. (To be fair,
I had not said this before.) It's fine to represent them as 32-bit
ints (or as CMUCL fixnums, actually). I'm not trying to squeeze every
last bit out of each field, as I wouldn't want to pay the speed price
for that in C. The big problem with my CL version is not about
bit-packing, it's about the fact that if what I want seems to be
naturally represented as an array of structs, I'm going to pay (under
CMUCL) an extra 3 machine words/object: one word because instead of
laying the objects directly into the array, I have an array of
pointers, and two more words because each struct has to have the
header that says what type it is, even though I know in advance that
they're all the same type.

(Note that in this application, because everything is actually an
integer, I can represent the array of structs as a single big array of
integers. I can develop syntax that hides this abstraction from the
algorithm, and this is what I'm likely to do. If I had a mix of
"individually well-aligned" types, things would be tougher --- I'd
have to use parallel arrays to do it cleanly in CL, and my locality of
reference would suck, even in the case where everything laid out
nicely in C.)

So actually, I don't care about the mixture between bytes, longs,
ints, and floats. I care about the fact that I'm paying 3 extra
machine words for each struct before I even get to the "data" for the
struct itself.

I still don't know what "C-centric" means in the context of this
conversation. I suspect I misunderstood your point; I apologize in
advance.

rif

> > ps. I've been posting in this forum for a couple years now. You can
> > refer to me as "rif" rather than "the OP" if you want.
>
> If you're asking me to be less impersonal, then that is hard to do
> with just a handle, even if it is part of your name, so I don't see
> "rif" as any more personal than "the OP". If you truly prefer to be
> called "rif" than Ryan or Michael, then I suppose I could do that,
> though that doesn't tend to be my style.

Well, I'm not asking you to do anything (although I'll appreciate it
if you continue enlightening me), I'm simply inviting you. Ryan
Rifkin is my name. Rif is the nickname I generally go by, and it's
what most people call me. If you're more comfortable with "The OP" or
"Mr. Rifkin" that's fine. I might object to derogatory epithets, but
that doesn't seem to be much of a problem in this forum.

Relevant Pages

  • Re: contiguity of arrays
    ... Couldn't arrays of ints have stricter alignment ... you can get around that by converting to a character pointer ... > That's because there is only one such array for a given effective type. ... If an object is declared as a struct, ...
    (comp.lang.c)
  • Re: contiguity of arrays
    ... >> What you seem to be saying is that for a region of memory to constitute ... >> an array of four ints, it doesn't have to be declared with a type that ... A struct type that consists of four ints ...
    (comp.lang.c)
  • struct question - C Programming
    ... Would it work if I just made 1 struct? ... can I dynamically allocate memory for the array of ints at ... the compiler doesn't know how big the struct is at compile time? ...
    (comp.programming)
  • Re: Is a byte data type really a 32-bit int in the JVM?
    ... specifically, if I have an an array of N byte types, are N 32-bit ints actually allocated underneath? ... Maybe you don't care, but the OP does care, with good reason. ... JVM implementers not being idiots, and arrays of bytes being used all ...
    (comp.lang.java.programmer)
  • passing arrays
    ... I have struct with a long intarray. ... int) which receives an array of long ints. ... John ...
    (comp.programming)