On Sat, Oct 23, 2010 at 5:13 PM, Graham Leggett <[email protected]> wrote: > On 23 Oct 2010, at 10:24 PM, Jeff Trawick wrote: > >>>> No; this is a dis-optimization. You have added int-bitmath cpu cycles >>>> to a simple int test, without gaining any storage. Huh? >>> >>> Are you sure? >>> >>> I would expect a compiler optimiser to do the most appropriate thing, and >>> it >>> gets us out of the habit of allocating an int or a char every time we >>> need a >>> boolean flag. >> >> It can't reorder fields, and pointers and integers need to be on >> "natural" boundaries for performance (or even outright functionality >> on some platforms). So there will be padding after the bit. >> >> Some Intel ABI spec would show alignment requirements for a notable >> example platform, absent of any packing pragmas. > > I was referring specifically to the "int-bitmath cpu cycles". Any data size > smaller than the bus width involves an AND at least, just to isolate the > byte or int. It's been a while since I was doing pure assembly, but would be > surprised if this was slower.
I dunno about any load-bit instructions... Seems like the bit field always has an extra step compared with the int for the platforms where I have a laughable recollection of assembly. But these bit fields are only for merging logic, right? Hardly a performance concern, even with htaccess compared with stat and all that. (It is nicer to have the is-set flag next to the related field, but I guess that's nothing to lose sleep over.)
