[Click] CLICK_BYTE_ORDER

[Koen Beel]

It is indeed possible to save space with bitfields, but I really don't
think this matters here. A few bytes more or less for an instance of
an element ...
Besides: if bitfields are more efficient, why sometimes use them and
sometimes not? (no offence, just asking)

And, AFAIK, a bitfield takes at least the space of it's underlying
datatype. So when you define a bitfield with only one 'bool a : 1;'
you take as much space as if you would write 'bool a;'

And because of the fact that most machines (where Click runs on) are
only byte addressable, the compiler has to use bitmasks to get data
out of the bitfields. And this is slower.

I did a test on gcc:

reading and writing the a in:

struct foo {
  bool a : 1;
};

is slower than in (one more instruction for a read or a write)

struct foo {
  bool a;
};

Reading foo::a about 1<<30 times:
-using O3 took more than 7 times longer when using bitfields (less
then 80ms against more then 600ms)
-using O1 took almost 40% longer (1.34s against 1.88s)

I really don't know if all this matters, but I do know dat bitfields
are a little slower and don't always save a significant amount of
space (i'm talking about byte addressable machines)
I just wondered why bitfields where used here. And honestly I'm not
convinced about their usefulness for saving space in this situation
... (again, no offence)


-- Koen

On 8/4/06, Eddie Kohler <kohler at cs.ucla.edu> wrote:
> I would really want to see some evidence that the difference between the
> bitmask and the nonbitmask mattered for some configuration.  One uses
> bitfields, as here, to save space.
>
> Eddie