On Mon, 2017-01-09 at 11:37 -0500, Alan Conway wrote: > ... > They're not used often because people tend to be too busy to think > about struct packing, but they are an important perf tuning tool. It > can be the difference between a single bool packing into 1 bit at > best > vs 64 at worst. That can easily double the size of a small structure > that gets allocated by the millions, or force cache misses on the > critical path. It often is not very important but sometimes it really > is. >
While this may be true in some cases, more often there are negative effects of bitfields - namely that they cannot be atomic, as the usual limit to atomicity in modern architectures is the word (or at least the byte). This means that every bitfield access in memory must be read-modify- write (if the compiler can keep the packed struct in registers then this gets much better). It also means that thread atomic bools can't be single bits anyway - they need a mutex as well. So they may as well just use the minimal atomic int size. So as a general rule, unless you have really large numbers of bools in your struct - like more than 64 of them (which might be more than a cache line on some archs if you map bools -> bytes) I think it's better to use non bitfield bools. However like all general advice it is subject to actually measuring the thing you care about (performance or memory or whatever). My previous experience has been that the major use of bitfields has been in mapping low level hardware register layouts into structs. Oviously in conjunction with controlling packing and big vs little endian knowledge. Andrew --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
