alignment在C ++ 11中的性能真的很重要吗？
alignment在C ++ 11中的性能真的很重要吗？
在Stroustrup的书中有一个build议来命令从最大到最小的结构中的成员。 但是我想知道是否有人做了测量，看看这是否有什么区别，以及编写代码时是否值得思考。
对准不仅关系到performance，还关系到正确性。 如果数据未正确alignment，或者访问错误的内存位置，某些体系结构将失败并显示处理器陷阱。 在其他方面，访问未alignment的variables被分解为多个访问和位移（通常在硬件内部，有时由操作系统陷阱处理程序），失去primefaces性。
按大小递减顺序排列成员的build议是为了最佳的包装/最小的空间浪费填充，而不是alignment或速度。 除非您使用特殊的编译指示（即非便携式#pragma pack ）或关键字请求不符合的布局，否则成员将被正确alignment。 尽pipe整个结构尺寸受填充影响并且也影响速度，但通常还有另一种最佳的sorting。
为了获得最佳性能，您应该尝试将一起使用的成员放到同一个caching行中，并将不同线程访问的成员放到不同的caching行中。 有时这意味着需要大量的填充来在自己的caching行中单独获取跨线程共享variables。 但是这比从虚假分享中获得性能要好。
只要加上本的伟大答案：
按照以后在应用程序中访问的顺序定义结构成员将减lesscaching未命中并可能提高性能。 如果整个结构不适合L1caching，这将工作。
另一方面，从大到小的顺序可能会降低整体内存使用量，这在存储小型结构数组时可能很重要。
假设对于一个架构（我不太了解他们，我认为默认设置32位gcc就是这种情况，有人会在意见中纠正我）这个结构：
struct MemoryUnused { uint8_t val0; uint16_t val1; uint8_t val2; uint16_t val3; uint8_t val4; uint32_t val5; uint8_t val6; }
在内存中占用20个字节，而这个：
struct MemoryNotLost { uint32_t val5; uint16_t val1; uint16_t val3; uint8_t val0; uint8_t val2; uint8_t val4; uint8_t val6; }
将采取12。由于填充，这是8个字节丢失，这是一个小结构的大小增加了67％。 有了大量这样的结构，增益将是显着的，并且，仅仅因为使用的内存量，将会减less高速caching未命中的数量。
