From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2007-10-03 05:43:03
Michael Marcin wrote:
> I like being able to depend on the order of private members. It allows
> me to nicely encapsulate my data while using SIMD operations internally.
You use SIMD operations on non-uniform data? What kind?
> I can imagine a cache performance degradation because it reorders my
> members to make the class size smaller but must access memory randomly
> in order to initialize them in the constructor in the order they
> appeared in the class definition instead of accessing them with
> ascending addresses if they were laid out the order in which they were
Possible, but not very likely on today's desktop systems, given typical
class sizes. A L1 cache line on x86 usually has 64 bytes - enough for 16
integers/pointers, still enough for 8 pointers on x86-64. Thus, any
object not exceeding this size would always fit into one cache line, and
there is no penalty to accessing the single line in random order. And
let's not forget that it might be _because_ of the reordering that the
object has shrunk to 64 bytes in the first place.
On the other hand, if the compiler sees that the object IS larger, it
could simply not reorder the elements.
I find the argument about binary compatibility more convincing. It would
indeed be tricky to work out good, predictable rules.
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk