[Click] CLICK_BYTE_ORDER

[Eddie Kohler]

OK, OK; I've updated the CheckIPHeader code to use raw bools :)

Eddie


Koen Beel wrote:
> 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