C++ Low level performance optimize 2

提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

C++ Low level performance optimize 2

上一篇文章讨论了一些底层代码的优化技巧，本文继续讨论一些相关的内容。

首先，上一篇文章讨论cache missing的重要性时，用了list做比较，目的并不是说list没有用，而是说明cache missing会对性能有重要影响。如果元素不多，并且对象复制的代价很大，那么list可能就是更好的选择。其次，这里讨论的大部分是编码时一些比较底层的技巧，当遇到性能问题时，应该先考虑是否能在高层改进算法，减少运算，实在不行，在考虑这类优化技巧。性能优化的挑战就在于没有完美的永远适用的方案，了解这些技巧让我们在优化代码时有更多武器，但最终选择哪个方案还需要更加实际情况，并且以profile的实际数据为依据来做。

1. Data Layout

调整数据布局是常见的优化手段，做此类优化时有几点需要注意：首先是内存占用，现代编译器默认大多以16或32位对齐，因此

struct BadLayout
{
int8_t i0;
int32_t i1;
int8_t i2;
};struct GoodLayout
{
int8_t i0;
int8_t i2;
int32_t i1;
};

sizeof(Goodlayout) >= sizeof(BadLayout) 在vs2013默认对齐设置下，BadLayout==12 byte，GoodLayout==8byte。

其次，经常访问或者相关的数据应该放到一起，减少cache missing。Going native2013 Andrei Alexandrescu介绍了facebook做的重要性能优化就是把php代码编译为c++代码，而在代码转换中重要的一步就是根据数据的”hotness”重新布局。

struct BadLayout
{
auto user0_data0;
auto user1_data1;
auto user0_data1;
auto user1_data0;
};struct GoodLayout
{
auto user0_data0;
auto user0_data1;
auto user1_data0;
auto user1_data1;};

最后，可维护性！这一点非常重要，对于一些生命周期较长的项目来说，把数据按逻辑组织更易于维护，减少潜在bug的重要性，如果性能差别不大，我通常更愿意让代码看起来好读J

2. Code cache

struct BitBool
{
bool b0 :;
bool b1 :;
bool b2 :;
}struct NormalBool
{
bool b0;
bool b1;
bool b2;
}

上次的例子中，这段代码比较有争议，让我们从时间和空间方面来分析。时间上，因为BitBool需要额外指令来访问元素，因此效率一定比NormalBool低，但差别非常小，几乎可以忽略。再看空间上，但从结构本身看，显然BitBool更小，但是由于访问元素需要额外指令，实际应用中，生成的代码一定比NormalBool多，读取访问的次数越多，生成的代码也越多(内联的结果)，而代码也需要占用内存空间！！cache line中通常一半是代码，一半是数据。因此，不一定因为BitBool本身小就得到更好的cache。大部分文章在讨论cache missing时都只介绍了数据，而忽略了代码也需要占用内存，也会有cache missing。某些游戏引擎会在update entity时先把对象按照类型排序，就是为了减少代码的cache missing。

最后，这个例子的目的是让大家了解过度优化可能并不会带来性能提升，实际应用中两种写法的虽然有性能差距，但基本可以忽略。

3. more about bit field

上一个例子让我想起了bitfield另一个微妙的地方，假设f1和f2在两个不同线程中，考虑下面代码是安全的吗？

struct BitField
{
bool b0 : ;
bool b1 : ;
bool b2 : ;
uint8_t i0 :;
}BitField bf;
std::mutex mtx1;
std::mutex mtx2;
//thread 1
void f1()
{
mtx1.lock();
bf.b1 = somevalue;
mtx1.unlock();
}
//thread 2
void f2()
{
mtx2.lock();
bf.i0 = somevalue;
mtx2.unlock();
}