【介绍】
本文完整的描述了C++语言的性能优化方法,从编译器、算法、语言特性、硬件、Linux等多个角度去考虑问题,文章技术含量很高,值得一看。
来源:http://www.whysearch.org/a/zh_CN/date/20110824
作者:冲出宇宙
【目录】
第一章性能优化原理
第二章善用编译器
第三章算法为王
第四章c++语言特性
第五章理解硬件
第六章linux系统
1、性能优化原理
在谈论性能优化技术之前,有几点大家一定要明确。第一点是必须有编写良好的代码,编写的很混乱的代码(如注释缺乏、命名模糊),很难进行优化。第二点是良好的构架设计,性能优化只能优化单个程序,并不能够优化蹩脚的构架。不过,网络如此发达,只要不是自己乱想的构架,只要去积极分析别人的成功构架,大家几乎不会遇到蹩脚的构架。
1.1、计算函数、代码段调用次数和耗时
函数的调用次数比较好说,用一个简单的计数器即可。一个更加通用的框架可能是维护一个全局计数,每次进入函数或者代码段的时候,给存储的对应计数增加1。
为了精确的计算一段代码的耗时,我们需要极高精度的时间函数。gettimeofday是其中一个不错的选择,它的精度在1us,每秒可以调用几十万次。注意到现代cpu每秒能够处理上G的指令,所以1us内cpu可以处理几千甚至上万条指令。对于代码长度少于百行的函数来说,其单次执行时间很可能小于1us。目前最精确的计时方式是cpu自己提供的指令:rdtsc。它可以精确到一个时钟周期(1条指令需要消耗cpu几个时钟周期)。
我们注意到,系统在调度程序的时候,可能会把程序放到不同的cpu核心上面运行,而每个cpu核心上面运行的周期不同,从而导致了采用rdtsc时,计算的结果不正确。解决方案是调用linux系统的sched_setaffinity来强制进程只在固定的cpu核心上运行。
有关耗时计算的参考代码:
//通常计算代码耗时
uint64_tpreTime=GetTime();
//代码段
uint64_ttimeUsed=GetTime()-preTime;
//改进的计算方式
structTimeHelper{
uint64_tpreTime;
TimeHelper():preTime(GetTime())
{}
~TimeHelper(){
g_timeUsed=GetTime()-preTime;
}
};
//调用
{
TimeHelperth;
//代码段
}
//g_timeUsed保存了耗时
//得到cpu的tickcount,cpuid(重整时钟周期)消耗约300周期(如果不需要特别精确的精度,可以不执行cpuid
inlineuint64_tGetTickCPU()
{
uint32_top;//input:eax
uint32_teax;//output:eax
asmvolatile(
"pushl%%ebx\n\t"
"cpuid\n\t"
"popl%%ebx\n\t"
:"=a"(eax):"a"(op):"cc");
uint64_tret;
asmvolatile("rdtsc":"=A"(ret));
returnret;
}
//得到cpu的主频,本函数第一次调用会耗时0.01秒钟
inlineuint64_tGetCpuTickPerSecond()
{
staticuint64_tret=0;
if(ret==0)
{
constuint64_tgap=1000000/100;
uint64_tendTime=GetTimeUS()+gap;
uint64_tcurTime=0;
uint64_ttickStart=GetTickCPU();
do{
curTime=GetTimeUS();
}while(curTime<endTime);
uint64_ttickCount=GetTickCPU()-tickStart;
ret=tickCount*1000000L/(curTime-endTime+gap);
}
returnret;
}
1.2、其他策略
除了基本的计算执行次数和时间外,还有如下几种分析性能的策略:
a、基于概率
通过不断的中断程序,查看程序中断的位置所在的函数,出现次数最多的函数即为耗时最严重的函数。
b、基于事件
当发生一次cpu硬件事件的时候,某些cup会通知进程。如果事件包括L1失效多少次这种,我们就能知道程序跑的慢的原因。
c、避免干扰
性能测试最忌讳外界干扰。比如,内存不足,读内存变成了磁盘操作。
1.3、性能分析工具-callgrind
valgrind系列工具因为免费,所以在linux系统上面最常见。callgrind是valgrind工具里面的一员,它的主要功能是模拟cpu的cache,能够计算多级cache的有效、失效次数,以及每个函数的调用耗时统计。
callgrind的实现机理(基于外部中断)决定了它有不少缺点。比如,会导致程序严重变慢、不支持高度优化的程序、耗时统计的结果误差较大等等。
我们编写了一个简单的测试程序,用它来测试常见性能分析工具。代码如下:
//计算最大公约数
inlineintgcd(intm,intn)
{
PERFOMANCE("gcd");//全局计算耗时的define
intd=0;
do{
d=m%n;
m=n;
n=d;
}while(d>0);
returnm;
}
//主函数
intmain(){
intg=0;
uint64_tpretime=GetTickCPU();
for(intidx=1;idx<1000000;idx++)
g+=gcd(1234134,idx);
uint64_ttime=GetTickCPU()-pretime;
printf("%d,%lld\n",g,time);
return0;
}
callgrind运行的结果如下:
我们把输出的结果在windows下用callgrind的工具分析,得到如下结果:
1.4、g++性能分析
gprof是g++自带的性能分析工具(gnuprofile)。它通过内嵌代码到各个函数里面来计算函数耗时。按理说它应该对高度优化代码很有效,但实际上它对-O2的代码并不友好,这个可能和它的实现位置有关系(在代码优化之后)。gprof的原理决定了它对程序影响较小。
下图是同样的程序,用gprof检查的结果:
我们可以看到,这个结果比callgrind计算的要精确很多。
在前一章,我们对分析代码和函数性能的策略进行了介绍。本章将介绍算法在程序性能方面的作用。
如果没有看过第一章的兄弟,在这里查看:第一章性能分析原理。
2算法为王
算法是程序的核心,一个程序的好坏,大部分是看起算法的好坏。对于一般的程序员来讲,我们无法改变系统和库的调用,只能根据规则来使用它们,我们可以改变的是我们自己核心代码的算法。
算法能够十倍甚至百倍的提高程序性能。如快排和冒泡排序,在上千万规模的时候,后者比前者慢几千倍。
通常情况下,有如下一些领域的算法:
A)常见数据结构和算法
B)输入输出
C)内存操作
D)字符串操作
E)加密解密、压缩解压
F)数学函数
本文不是讲解算法和数据结构,所以,我们不展开。
2.1选择算法
程序里面使用最多的是检索和排序。
map是一种很通用的结构(如c++里面的std::map或者java的TreeMap),一般的语言都是用红黑树来实现。红黑树是一种读写性能比较均衡的平衡二叉树。
对于排序来说,std::sort采用的是改进的quicksort算法,即introsort。这种算法在递归层次较深的时候,改用堆排序,从而避免了快排进入“陷阱”(即O(N)复杂度)。Introsort是公认的最好的快速排序算法。
平常的排序用introsort即可,但在遇到大规模字符串排序的时候,更好的一个策略是采用基数排序。笔者的经验是,千万量级时,基数排序在字符串领域比introsort快几十倍。有很多研究论文探讨基数排序在字符串领域的应用,大家可以去看看,如:EfficientTrie-BasedSortingofLargeSetsOfStrings。
在某些情况下,如果数组基本有序的话,可能希尔排序也是一个好选择。希尔排序最重要的是其每次选择的数据间隔,这个方面有专门的研究可以参考。
至于其他的特殊算法,如多个有序数组归并等等,大家可以在实际情况中灵活应变。
2.2算法应用优化策略
在实际应用中,有一些基本的优化策略可以借鉴。如:
A)数组化
这条策略的逻辑很简单:访问数组比访问其他结构(如指针)更快。基于这种考虑,我们可以把树结构变成数组结构。数组平衡树,它把一个通常的平衡树修改为数组的形式,但编程比较复杂。双数组Trie树,用2个或者多个数组来描述Trie树,因为trie树是一个多叉树,变成数组后,性能可以提高10多倍。数组hash,hash表用数组描述,最方面最有名的结构是bloomfilter和cuckoohash。
参考:双数组Trie树
参考:bloom-filter
B)大节点化
如果一个节点(树或者链表等)长度太小,那么单个数据命中cpucache的概率就很低。考虑到cpucacheline的长度(如64字节),我们需要尽量把一个节点存放更多的数据。B树就是这样的一种结构,它一个节点保存了大量连续数据,能有效利用cache。JudyArray也是通过谨慎安排树节点的长度来利用cache。列表结构,一个节点存放多个数据,也能提高cache命中率。
2.3内存管理算法
常见的内存管理算法有很多,如First-Fit、Best-Fit、Buddy-system、Hal-Fit。每个程序根据自己的特点会采用不同的算法,没有绝对好的算法。比如,内核可能采用Buddy-System。有1个比较经典的算法大家需要清楚,即c语言的内存分配malloc算法。我们目前在各种系统中看到的算法,比如memcached、nginx等,都是这种算法的简单变形。
参考:malloc
malloc算法根据空闲内存块大小进行分段,每个段有一个字节范围,在这个范围内的空闲内存块都挂在对应链表上面。分配内存的时候,先找到对应的段,然后取链表的第一个内存块分配即可。
TLSF算法是号称最好的内存分配算法。它也是malloc算法的一种变形。
参考:tlsf
2.4库的选择
毫无疑问,首选glibc/stl库,因为他们被论证多年,并且,同样的算法,很难写出更好更快的代码。
第二可以考虑boost库,但建议只用那些最常见的功能。
ACML和MKL也是一种高性能的库,他们对向量计算很友好。
对于各种开源库,如glib/apr/ace/gsl/crypto++等等,必须考虑它们开源的协议,避免使用商业收费的协议。对于安装服务器比例不高的库,也尽量不要使用,因为开源库代码都不加什么注释,出错很难查。
在前一章,我们对常见算法的选择做了些简单的说明。本章将介绍g++编译器在性能优化中的重要作用。
如果没有看过第二章的兄弟,在这里查看:第二章算法为王。
3善用编译器
算法能够十倍、几十倍的提高程序性能,但当算法已经很难改进时,还有一种简单的办法提高程序性能,那就是微调编译器。利用编译器提供的各种功能,你能够轻松的提高几倍的程序性能。
大家要记住的是,编译器绝对比想象的要强大的多。编写编译器的人大都是十年、几十年代码编写经验的科学家!你能简单想到的,他们都已经想到过了。普通的编译器,可以支持大部分已知的优化策略以及多媒体指令。
至于哪个编译器更好?大部分人的观点是:intel。Intel毕竟是最优秀的cpu提供者,他们的编译器考虑了很多cpu的特性,跑的更快。但目前intel编译器有一些比较弱智的地方,即它只识别自己的cpu,不是自己的cpu,就认为是最差的i386-i686机器,从而不能在amd等平台上面支持sse功能。我们在linux上面写代码,一般更加喜欢流行的编译器,比如gcc。
Gcc的优点是它更新快,开源,bug修改迅速。正因为他更新快,所以它能够支持部分C03的规范。
3.1gcc支持的优化技术
1)函数内联
函数调用的过程是:压入参数到堆栈、保护现场、调用函数代码、恢复现场。当一个函数被大量调用的时候,函数调用的开销特别巨大。函数内联是指把这些开销都去除,而直接调用代码。函数内联的不好之处是难以调试,因为函数实际上已经不存在了。
2)常量预先计算
a=b+1000*16
对于这段代码,程序会预先计算1000*16,从而变成:
a=b+16000
3)相同子串提取
a=(b+1)*(b+1)
这里,b+1需要计算2次,可以只用计算一次:
tmp=b+1
a=tmp*tmp
4)生存周期分析
这是一个比较高级的技术。假设有代码:
a=b+1
c=a+1
在执行的时候,因为第二句依赖第一句,所以2句是线性执行。
但编译器其实可以知道,c就是等于b+2,所以代码变成:
a=b+1
c=b+2
这样,这2句就没有任何关系来了,执行的时候,cpu可以并行执行它们。
5)清除跳转
看如下代码:
intfunc()
{
intret=0;
if(xxx)
ret=5;
elseif(yyy)
ret=6;
returnret;
}
当条件xxx满足的时候,程序还会跳到下面执行,但其实是没有必要的。编译器会把它变成:
intfunc()
{
if(xxx)
return5;
elseif(yyy)
return6;
}
6)循环展开
循环由几个部分组成:计数器赋值、计算器比较、跳转。每次循环,后面2步都是必须的消耗。把循环内的代码拷贝多份,可以大大减少循环的次数,节约后面2步的耗时。参考:
for(intcounter=0;counter<4;count++)
xxx;
可以变成:
xxx;
xxx;
xxx;
xxx;
编译器不仅仅可以展开普通循环,它还能展开递归函数。原理是一样的,递归其实是一个不定长的借用了堆栈的循环。
7)循环内常量移除
for(intidx=0;idx<100;idx++)
a[idx]=a[idx]*b*b;
因为b*b在循环体内的值固定(常量),所以代码可以变成:
tmp=b*b;
for(intidx=0;idx<100;idx++)
a[idx]=a[idx]*tmp;
8)并行计算
大家都知道,现代cpu支持超流水线技术,同时可以执行多条语句。多条语句能否同时执行的限制是不能互相依赖。编译器会自动帮我们把看起来单线程执行的代码,变成并行计算,参考:
d=a+b;
e=a+d+f;
可以变成:
tmp=a+f;
d=a+b;
e=d+tmp;
9)表达式简化
当年笔者在学习《离散数学》和《数字电路》的时候,总被眼花缭乱的布尔运算简化题目难倒。gcc终于让我松了一口气。参考:
!a&&!b
这句需要3步执行,但变成:
!(a||b)
只需要2步执行。
3.2gcc重要优化选项
1)内联
Ø-finline-small-functions
内联比较小的函数。-O2选项可以打开。
Ø-findirect-inlining
间接内联,可以内联多层次的函数调用。-O2选项可以打开。
Ø-finline-functions
内联所有可以内联的函数。-O3选项可以打开。
Ø-finline-limit=N
可以进行内联的函数的最小代码长度。注意,这里是伪代码,不是真实代码长度。伪代码是编译器经过处理后的代码。带inline等标志的函数,默认300行代码即可内联,不带的默认50行代码。和这个相关的选项是max-inline-insns-single和max-inline-insns-auto。
Ømax-inline-insns-recursive-auto
内联递归函数时,函数的最大代码长度。
Ølarge-function-insns、large-function-growth、large-unit-insns等
函数内联的副作用是它导致代码变多,程序变长。这里的几个参数可以控制代码的总长度,避免编译后出现巨大的程序,影响性能和浪费资源。
2)-fomit-frame-pointer
不采用标准的ebp来记录堆栈指针,节省了一个寄存器,并且代码会更短。但据说在某些机器上面会导致debug模式出错。实际测试表明,在gcc4.2.4以下,O2和O3都无法打开这个选项。
3)-fwhole-program
把代码当做一个最终交付的程序来编译,即明确指定了不是编译库。这个时候,编译器可以使用更多的static变量,来加快程序速度。
4)mmx/ssex/avx
多媒体指令,主要支持向量计算。一般来说,-march=i686、-mmx、-msse、-msse2是目前机器都支持的指令。
除了基本的多媒体支持外,gcc编译器还支持-ftree-vectorize,这个选项告诉编译器自动进行向量化,也是-O3支持的选项。
多说几句。在平常的使用中,多媒体指令不是很常见(除非游戏)。如果你有几个位表(bitset),它们需要进行各种位操作的话,多媒体指令还是挺有效果滴。
3.3gcc大杀器-profiledrivenoptimize
这是比较晚才出现的技术。其基本原理是:根据实际运行情况,缩短hot路径的长度。编译器通过加入各种计数器来监控程序的运行,然后根据计算出来的实际访问路径情况,来分析hot路径,并且缩短其长度。根据gcc开发者的说法,这种技术可以提高20-30%的运行效率。
其使用方式为:
Ø编译代码,加上-fprofile-generate选项
Ø到正式环境一段时间
Ø当程序退出后,会产生一个分析文件
Ø利用这个分析文件,加上-fprofile-use,重新编译一次程序
举个例子来说:
a=b*5;
如果编译发现b经常等于10,那么它可以把代码变成:
a=50;
if(b!=10)
a=b*5;
从而在大多数情况下,避免了乘法消耗。
3.4gcc支持的优化属性(__attribute__)
Øaligned
可以设置对齐到64字节,和cpu的cacheline看齐
Øfastcall
如果函数调用的前面2个参数是整数类型的话,这个选项可以用寄存器来传递参数,而不是用常规的堆栈
Øpure
函数是纯粹的函数,任何时刻,同样的输入,都会有同样的输出。可以很方便依据概率来优化它。
3.5gcc其他优化技术
Ø#pragmapack()
对齐到一个字节,节省内存
Ø__builtin_expect
直接告诉编译器表达式最可能的结果,方便优化
Ø编译带debug信息的小文件
以下代码能够大大减少编译后程序大小,同时保留debug信息。其原理是外链一个带debug的版本。
g++tst.cpp-g-O2-pipe
copya.outa.gdb
strip--strip-debuga.out
objcopy--add-gnu-debuglink=a.gdba.out
在前一章,我们对gcc编译器的性能优化策略进行了简单描述。本章将介绍和c++语言相关的性能优化技术。
如果没有看过第二章的兄弟,在这里查看:第二章善用编译器。
4C++代码优化
C++语言博大精深,作为一个不到10年的使用者,笔者并没有多少经验,只能通过学习,看源码来形成一些自己的想法。
4.1变量存储
1、数据区
可执行文件包含多个区域,有代码区,数据区等。一般的c++编译器,会把全局变量、static变量、float/double/string常量、switch跳表、初始化变量列表、虚函数表等存放到数据区域。int变量一般会存储在代码区,和指令放到一起。
略解释一下初始化变量列表:intd[]={1,2,3};
2、堆栈区
堆栈区域保存函数调用、上下文、局部变量。因为局部变量存储在堆栈区,所以访问局部变量很可能会命中cpu的cache,其速度很快。
3、堆
申请的内存(如通过new)。
4.2变量优化
1、使用成员初始化和构造初始化列表
它们都可以避免2次赋值(即初始化后再赋值)。如:
pubilcC():x(10)
{}
和
std::stringstr("java");
避免使用:
std::stringstr="java";
2、堆栈最快
上面已经说过,因为cache的原因,堆栈变量访问速度很快。
Ø缩短变量周期
让变量更快速的结束,有2个好处:占用的位置可以给下面的变量使用、编译器甚至可以用寄存器来存储变量。
Ø延期申请
变量距离上一个使用过的变量近,被cache概率高。
3、参数传递
为了降低函数调用的开销,当有多个参数时,最好把参数组合成一个结构。
4、返回变量
Ø返回构造形式
避免2次拷贝。如:
returnstring("java");
要比
return"java";
更快。
Ø用引用代替返回
避免构造对象。在函数调用的时候,把需要返回的对象都用引用传递进来。如:
voidfunc(Object&retObj);
5、变量紧密定义
关联度很高的变量可以定义在一起。举例来说:
inta[N],b[N];
for(intidx=0;idx<N;idx++)
a[idx]=b[idx];
修改成:
struct{
inta,b;
}d[N];
for(intidx=0;idx<N;idx++)
d[idx].a=d[idx].b;
后者因为a,b紧密定义在一起,其访问对cache更友好。
6、类/结构成员顺序
因为默认对齐的原因,成员变量的顺序对对象的空间占用有一定影响。一般把变量按照字节大小从前往后放。比如:
struct{
doubled;
inti;
shorts;
boolb;
}
其size是16字节。但:
struct{
boolb;
doubled;
shorts;
inti;
}
其size是20字节。
例外的是数组成员。一般认为数组成员应该往后放。这是因为访问其他变量的时候,相对偏移(结构的初始位置)比较小,代码更短。如:
moveax,[ebp+10h]显然比moveax,[ebp+256h]实际代码要短。
4.3函数内联
函数内联作为编译器最大最好的优化选项,无论在哪里都值得探讨一番。函数内联的好处是节省了保护现场和返回值的开销。编译器并不是万能的,有些函数很容易进行内联,有些函数则很难进行内联。
对编译器友好的函数,一般代码比较短,函数没有递归逻辑。对编译器不友好的函数,显然就是指:函数指针调用、深度递归、虚函数。函数指针调用,会让编译器不知道真实的函数在哪里,既然都不知道函数在哪里,自然无法内联了。虚函数也是一样的问题,编译器不清楚调用的方法在哪里。
有一种策略可以把虚函数变成可以内联的函数,下面在重点讨论这个策略。假设我们的程序如下:
structCParent{
virtualintf(){
return0;
}
};
structCChild1:CParent{
intf(){
return1;
}
};
structCChild2:CParent{
intf(){
return2;
}
};
调用语句如下:
intcount=0;
vector<CParent*>ds;
vector<CParent*>::iteratoriter=ds.begin();
while(iter!=ds.end())
{
count+=(*iter)->f();
iter++;
}
毫无疑问,程序在编译的时候,不可能知道f函数到底是CChild1::f还是CChild2::f。我们通过加一个内置的type,来明确告诉编译器到底是f是哪个真正的函数:
structCParent{
inttype;
virtualintf(){
return0;
}
};
structCChild1:CParent{
CChild1(){
type=1;
}
intf(){
return1;
}
};
structCChild2:CParent{
CChild2(){
type=2;
}
intf(){
return2;
}
};
inlineintf(CParent*p){
switch(p->type){
case1:
return((CChild1*)p)->CChild1::f();
case2:
return((CChild2*)p)->CChild2::f();
}
return0;
}
//调用代码
intcount=0;
vector<CParent*>ds;
vector<CParent*>::iteratoriter=ds.begin();
while(iter!=ds.end())
{
count+=f(*iter);
iter++;
}
我们仅用一个switch语句就节约了函数调用的各种开销,很值得。事实证明,这种策略可以极大的提高程序效率。
4.4switch优化
switch有3种替换模式:
Øif
用if来替换switch。当switch的判断值数量少时,这种策略比较高效。
ØJumptable,跳表
用一个数组存储case包含的代码,而直接用case的值来跳转到代码位置。如:
switch(d){
case0:
xxx;
break;
case1:
yyy;
break;
...
}
变成:
addr={addr_xxx,addr_yyy};
jumpaddr[d];
但这个策略只适合判断的值比较连续的情况,这是因为数组下标连续。
ØLookuptable,查找表
查找表适合简单的逻辑,可以预先计算结果,然后直接根据某种逻辑返回结果。但一般需要编程者自己完成设计。比如:
ret={"a","b","c"}
returnret[d];
最后大家看一下switch语句的独特用法:
4.5最大概率路径最短化
这次策略的思想我们多次提到。有几种常见的方式来达到这个目的:
Øswitch/if/?x:y
把最常见的情况放在前面,减少其比较次数。
Ø布尔表达式
在&&表达式时,把最不容易为true的放在前面。在||表达式时,把最容易为true的放在前面。
Ø函数内cache
可以用一个变量存储最常见的返回结果。如:
staticintcomm_input,comm_output;
if(input==comm_input)
returncomm_output;
xxx;
考虑到计算最常见的输入需要很多额外操作,故我们可以只存储最上一次的结果。
4.6异常
C++的异常有不少诟病,比如没有finally,出错时难以释放资源。它还需要大量额外的资源,因为需要保存那些变量没有被析构等信息。我们的建议是不使用异常,尽量通过自定义log以及assert的方式来处理程序异常。
在前一章,我们对c++语言和性能有关的部分进行了简单描述。本章将介绍和和cpu硬件相关的性能优化技术。
5理解硬件
Intel的cpu外部结构由著名的CPU、南北桥组成。北桥连接的都是快速设备,如内存和显卡。南桥则是低速设备,如磁盘、声卡等等。
图支持intel的主板
图intelcpu基本构架图
AMD的cpu'外部结构有所不同。其socket的接口为AM3,其内存控制器在cpu里面,可以直接连接内存。
图支持AMD的主板
图amdK10构架
5.1理解内存
我们现在使用的一般是DDR3代内存条,台式机的内存一般有240针,但内存的实际数据位数只有64位,即8个字节。
图台式机内存脚的说明
一般来说,内存的速度比cpu的速度慢。为了提高内存的数据传输速度,有人设计了多通道模式。在这种模式下,内存的传输速度可以加倍。多通道有双通道和三通道之说,后者仅最新的Intelcpu支持。多通道又分为Ganged和Unganged模式。前者每次提供128位数据,后者每次提供64位数据,但容许同时读取。实际结果表明,后者对多核多线程的服务器更加有效。(注:cpuz会把unganged模式识别为单通道+)
图多通道
5.2理解cpucache
现代cpu包含多级cache,一般为L1-L3共3级。下图是笔者对cpucache的分析图:
图cpucache分析
从图中我们可以看到,内存控制器(IMC)通过多个通道和内存(memorystick)连接。每个通道的位宽是64。内存控制器和L3cache的位宽是96。为啥是94位呢?这是因为在双通道模式下,内存控制器的进入位宽是128,而IMC的频率一般为内存频率的1.5倍(实际数据),如果出位宽是96,则IMC的频率差不多刚好够用(需要为内存频率的1.33倍)。
5.3cacheline的解释
有几点大家要明白:
n内存位宽是64;
nCpuLxcacheline是64字节;
Cache每次消耗8个时钟读取一个数据(从内存中)。
在双通道ganged模式下,只需要4个时钟的读取时间。
nLxcacheN-way的概念
内存中的数据,只能固定存储在Lxcache中的某些位置。对于32way的cache来说,每块内存中的数据(即把内存按照cacheline的长度切分)只能在32个位置中出现。这样的目的是加快cache的查找。
5.4内存速度
内存的速度很难计算,毕竟不是所有的指令都能让cpu和内存之间的通道全速工作。好在mov/movq指令可以比较全面的利用cpu流水线,能够测试出大概的内存速度。
对于DDR31333的内存和北桥(或者IMC)速度为1995M的cpu,我们大致可以计算如下:
ØDDR31333,ungangeddualchannel
理论带宽:1333*8*2=21G/s,访问延迟:几十个ns。
ØL3cache,NB-speed(1995M),on-die,48-way
理论带宽:1995*8=16G/s,访问延迟:10ns。
ØL2cache,full-speed,on-die
理论带宽2800*8=22G/s,访问延迟:几ns。
ØL1cache
理论带宽未知,访问延迟<1ns。
下面的图是EVEREST的测试结果:
5.5几个简单应用
第一个应用:快速2分查找。2分查找的主要问题是访问随机,对cache很不友好。我们根据查找树把元素重新排列,增加每个节点的数据个数。从而提高了cache的命中率。
图快速2分查找
第二个应用:最快速的内存拷贝。主要是3个步骤:1)预先读取指令,把数据读取到cpucache里面;2)采用mmx缓存器,有效利用cpu流水线;3)movn指令,直接写内存,不存放在Lxcache里面。
图最快的memorycopy
5.5多核的问题
图代码
图问题
在多核的情况下,cpu需要经常同步他们之间的cache。而每次同步都是以一个cacheline为单位。当多个核心cache了同样的line时,如果你不小心修改了line中的一个字节,也会导致整个line被同步。这就导致了本来和其他线程无关的数据,也会经常的被同步给它们。所以,我们建议在定义变量的时候,每个线程只写入位置超过一个line长度的变量。
5.6cpu指令集介绍
386:支持少量寄存器;
x64:64位,多了几个寄存器;
mmx、sseX:多媒体指令、适合向量计算;
avx:256为YMM寄存器,支持浮点(但只被新系统支持);
3dnow!:多媒体指令
在前一章,我们对cpu及其周边部分进行了简单描述。本章将介绍和和linux系统有关的一些通用性能优化技术。
6linux系统
系统对程序性能的影响很大,因为程序大量使用系统提供的核心库。从程序角度来看,耗时严重的地方主要是在IO处理,包括基本的磁盘读写、网络读写外,还包括系统对页的管理(会导致磁盘IO)。
6.1更快的磁盘IO
通常使用标准c/c++函数读取文件时,库和系统都会进行很多处理,如把数据在各自的buffer里面进行传递。
图文件读取示意图
Linux系统提供了底层open函数,加上设置O_DIRECT,可以跳过中间的cache,直接从磁盘读取(当然,磁盘设备自身的cache还会有)。有人测试表明,这种策略几乎不能提高(提高1-2%)顺序读取文件的速度。这种策略的最大好处其实不是跳过程序中间cache,而是跳过linux系统全局文件块缓存。全局文件块缓存会额外的消耗不少cpu和内存,考虑这点,加上减少的中间层cpu消耗,本策略能够大大降低cpu的消耗。从别人的测试结果中能够看到,在多线程同时进行磁盘IO时,本方法能够较大的提高性能。使用的时候,请注意它的对齐约束。
mmap策略是另外一个更好的办法,简单易用,并且没有open函数的系统调用开销。异步io(aio)是另外一个不错的减少等待的方式,不会阻塞当前线程。
6.2更快的网络IO
第一步,用epoll替换select。
select每次等待都会遍历所有的socket,而epoll每次都只用处理有事件的socket。在大量并发socket的情况下,它们的速度相差很远。
第二步,加快连接速度。
使用基本的connect函数,在连不上时(如服务器端口未监听),需要很久很久才会返回错误。一种解决方案是采用异步connect,不阻塞在当前线程;另外一种解决方案是设置IPTOS_LOWDELAY标志,让对方马上响应。参考代码:
boolSetLowDelay(int32_tsd){
#ifdefIPTOS_LOWDELAY
constinttos=IPTOS_LOWDELAY;
#else
constinttos=0x10;
#endif
returnsetsockopt(sd,IPPROTO_IP,IP_TOS,(char*)&tos,sizeof(tos))==0;
}
第三步,禁止Nagle算法。
这个算法会缓存数据,等数据达到一定大小后再一起发送。某些情况下,它会导致包发送速度变慢。通过设置TCP_NODELAY来禁止它。有人测试说,禁用Nagle算法会导致apache服务器吞吐变慢。参考代码:
boolSetDisableNagle(int32_tsd){
intbool_true=1;
returnsetsockopt(sd,IPPROTO_TCP,TCP_NODELAY,(char*)&bool_true,sizeof(bool_true))==0;
}
第四步,把socket缓存设置为最大。
如果有权限,可以先修改系统支持的最大缓冲大小,参考:
/sbin/sysctl-wnet.core.rmem_max
/sbin/sysctl-wnet.core.wmem_max
/sbin/sysctl-wnet.ipv4.tcp_mem
至于在程序中,可以通过SO_SNDBUF标志来修改socket的实际缓冲大小。有一种策略是用2分法来找到可以设置成功的最大缓冲值。
第五步,使用accept4替换accept。
通常在accept得到一个socketid之后,都会对socket进行一些基本的设置,这就产生了2次系统调用。而accept4函数可以直接设置socket的flag,减少了一次系统调用。
第六步,使用合适的网络层构架。
图网络层构架1
正如图中所示,本结构把socket交给单个线程管理,每个线程管理多个socket。这种结构的好处是耦合少,不用进行线程同步;额外开销少,适合单任务处理速度很快的情况。不好之处是在socket比较少时,难以使用所有线程的处理能力;二次发送数据间隔较长,导致实际处理缓慢。典型的系统见memcached、nginx。
另外一种网络结构统一管理socket,通过分发器来均匀分发任务,确保每个线程都繁忙。参考图:
这种结构统一管理任务,发送数据时异步缓存,保证线程一次发送成功。能够极限利用cpu的处理能力。其缺点是结构复杂,额外有不少消耗。目前电商搜索后台一般采用这种逻辑。
6.3少用swap
swap的工作原理是:系统自动的把它认为不重要的页从内存置换到磁盘,以提供内存空间给其他人使用。虽然其设计者认为在linux下应该把swappiness设置为100%,但在很多情况下,swap都会导致严重问题。
swap会导致机器死机。某些情况下,当某个程序的swap占用过大时,如果这个时候程序要退出或者不需要那么多页,系统会尝试把swap的数据置换到内存,以便进行下一步操作,如果这个时候内存不足以存放这些数据,就会导致死机。注:swap导致死机的问题,不知道大家有没有更好的解释?
一般来说,数据库和能够自带缓存的程序,都不希望系统把内存页置换出去。最简单的“阻止”swap的策略是修改系统参数,参考:
sysctl-wvm.swappiness=0
echo1>/proc/sys/vm/drop_caches
第一条语句是建议系统不要使用swap,第二条语句是让系统清理cache,以便释放更多内存。但第一条并不能够绝对阻止swap(因为只是建议)。
mlockall是程序比较常用的锁定内存的函数。它能够防止内存页被置换到swap。
6.4避免多线程写磁盘
多线程大量写入磁盘文件,如果是同一个文件有多个写入者,会导致同步的麻烦;如果是不同的文件,也会因为大量IO导致机器假死(如不接收网络连接)。通过调低vm.dirty_ratio和vm.dirty_background_ratio参数来降低系统文件写缓存能力,减少写入时大量的cpu耗用。
题外话,减少squid的coss文件的使用,因为coss文件消耗cpu也很严重。
6.5锁理论
多线程环境下,给资源加锁是很有技巧的事情。最简单的策略是尽量减少线程进入锁的时间。从理论上面讲,CAS是锁的基础。CAS即Compare&Swap,其原理很简单,就是一个基本的操作:如果n等于m,则把n和q交换。为啥CAS能够能够完美的支持锁呢?原理很复杂,参考论文《Wait-FreeSynchronization》。汇编语言的CMPXCHG就可以支持CAS。而G++自带的__sync_val_compare_and_swap/__sync_bool_compare_and_swap函数(支持CAS),仅在编译的时候用-march=i486以上时才生效。考虑到现在的intel和amd的都支持i686以上指令,可以直接换成-march=i686。
pthread_mutex是常用的锁模式。它的开销也不算大,但在大量调用的时候,还是对性能有影响。有人测试说,开100个线程,每个调用10w次,需要25秒。
atomic原子操作也很常用。因为它主要是对int类型进行处理,故经常在引用计数的地方看到它。
在高性能编程中,我们更有兴趣的是non-blocking算法(也叫lockfree)。这类算法能够不用加锁来进行多线程同步。常见的有以下两种策略:
1、circularbuffer(也叫ring)fifo
首尾相连的队列结构,一般用数组表示。用开始和结束指针来表示数据位置。参考:
这种结构适合一个线程写一个线程读的情况。
2、RCU(read-copy-update)
读取拷贝更新,意思就是说,在要进行update的时候,先保留旧数据,然后替换新数据;再等待旧数据无人使用后,删除旧数据。从它的思想可以看到它写入数据的开销比较大,因为要等待所有读取线程都不在使用旧数据为止。这种结构比较适合用在很多线程读,但只有少量写的地方。
Linux核心提供了基于RCU的锁函数。但在用户态下,需要自己调用其他库,如liburcu。
下图简单的描述了在实时索引技术里面使用的一种免锁机制:
图中是内存结构,每个色块代表一个内存数据,而白色的表示空闲内存。当来了新的数据,和橘色的块合并为一个新的块,把这个块存放到空闲内存的最底部。右边灰色的表示旧橘色数据的位置。
(完)
【附录】
文章相关链接:
http://hi.baidu.com/algorithms/blog/calendar/201108
http://www.whysearch.org/a/zh_CN/date/20110824
http://www.whysearch.org/a/zh_CN/date/20110826
http://www.whysearch.org/a/zh_CN/date/20110901
http://www.whysearch.org/a/zh_CN/date/20110902
http://www.whysearch.org/a/zh_CN/date/20110905
http://www.whysearch.org/a/zh_CN/date/20110922