作者主页http://www.chenshuo.com可下载测试文本与源代码
C++ Standard Template Library——STL的性能究竟如何,不同版本的STL其性能差异有多少?为了解这些,让我们来做一个简单的测试吧。
测试的基本思路是用C与C++分别实现一个程序,实现相同的功能,并要求C++程序的主要数据结构用STL中的Containers、Algorithms等来实现。然后比较两个程序的性能,看看究竟谁快,快多少。
因本人水C/C++水平极为有限,写的code实在拿不出手,为保证公平,最好用一位大家公认的大师级人物写的code来做这个测试。好在《The Practice of Programming》(中译本《程序设计实践》,裘宗燕译)第三章里,作者Brian W. Kenighan分别用C和C++写了实现相同功能的Code,他老人家的程序用在这里最合适不过了。这个程序是用来实现“马尔可夫(markov)链算法”的,关于markov链算法的详情请看本文附录1。
我在《The Practice of Programming》一书的主页 http://tpop.awl.com 下载到相应的代码,为了记录程序运行的时间,我在代码中加了几条语句(以“/* Added by Chen Shuo*/”标明),完整的代码见本文附录2。
测试用机:
机器一:PII 300 with 512k L2 Cache,Intel 440LX主板 66MHz外频,64M RAM,安装P – Win98 SE;
机器二:PII 350 with 512k L2 Cache,Intel 440BX主板 100MHz外频,128M RAM,安装Windows2000 Professional中文版with Service Pack 2。
编译环境:(均在Windows下编译)
1、 Microsoft Visual C++ 6.0 with Service Pack 5
2、 Cygwin : dll ver 1.3.2 与 GNU C++ 2.95.3 (下载自http://www.cygwin.com)
3、 Borland C++ Compiler 5.5.1 for free (下载自http://www.borland.com)
<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
共有三个文件要编译,分别是C版的markov.c;使用list的markov_l.cpp;使用deque的markov_d.cpp。其中markov.c需要和eprintf.c一同编译链接。
编译命令行参数(均已打开速度优化选项,编译的可执行文件在DOS Prompt中执行):
ps.我把BCC安装在C:\bcc,Cygwin安装在c:\cygwin。所以环境变量的设置办法是:
set MSDevDir=C:\PROGRA~1\MICROS~3\COMMON\msdev98
set MSVCDir=C:\PROGRA~1\MICROS~3\VC98
set PATH="C:\PROGRA~1\MICROS~3\VC98\BIN";c:\windows;c:\windows\command;c:\bcc\bin;
set PATH=%PATH%;C:\cygwin\bin "C:\PROGRA~1\MICROS~3\COMMON\msdev98\BIN";
set INCLUDE=C:\PROGRA~1\MICROS~3\VC98\INCLUDE;
set LIB=C:\PROGRA~1\MICROS~3\VC98\LIB;
1、以编译markov_l.cpp为例,为区别不同编译器生成的exe文件,需指定生成的EXE文件的名子,蓝色部分是生成的文件名。
g++ -o g_l.exe -O4 markov_l.cpp
bcc32 -Ic:\bcc\include -Lc:\bcc\lib -O2 -6 –eb_l.exe markov_l.cpp
cl /G6 /O2 /Og /GX /MT /Fev_l.exe markov_l.cpp
2、再以编译markov.c为例
g++ -o g_c.exe -O4 markov_l.c eprintf.c
bcc32 -Ic:\bcc\include -Lc:\bcc\lib -O2 -6 –eb_c.exe markov_l.c eprintf.c
cl /G6 /O2 /Og /MT /GX /Fev_c.exe markov.c eprintf.c
这样我们用三个编译器编译3个程序,就得到9个exe文件,分别是:
|
markov.c
|
markov_l.cpp
|
markov_d.cpp
|
GNU C++ 2.95.3
|
g_c.exe
|
g_l.exe
|
g_d.exe
|
BCC 5.5.1
|
b_c.exe
|
b_l.exe
|
b_d.exe
|
VC6
|
v_c.exe
|
v_l.exe
|
v_d.exe
|
为了验证各个程序的正确性,我用BCC 5.5带的license.txt(15095Bytes, 2239个词)作了简单的测试(如C:\BCC> b_d < license.txt ),各程序均能迅速给出结果。还需要一个较大规模的文本来作性能测试,我用的是英文版《简·爱》(JEAN EYRE)的Part II, Chapter 10 ~ Chapter 18,文件大小265635Bytes,46751个词,存为text1.txt。
测试办法:在命令行敲入
g_c <text1.txt >g1.txt
执行完后,打开g1.txt,最后一行”The time was:”是程序执行的时间,同时看看有没有生成10000个单词,若不足10000个,需要再次执行测试,这样才能保证测试的公平。
为了方便,我写了一个小程序自动进行测试:一个exe文件执行30次,生成30个txt文件。前三个不计,找出后27个文件中行数达到10000的,求出它们的平均执行时间。
在两台机器上做的测试结果如下,单位是秒:
|
PII 300 with 64M RAM
|
PII 350 with 128M RAM
|
b_c
|
0.432
|
0.330
|
b_d
|
>300*
|
5.567
|
b_l
|
>300*
|
5.607
|
g_c
|
0.463
|
0.336
|
g_d
|
3.366
|
2.581
|
g_l
|
2.142
|
1.707
|
v_c
|
0.568
|
0.459
|
v_d
|
>300*
|
131.6*
|
v_l
|
2.714
|
2.080
|
注:凡标有*者,在程序执行时硬盘狂响,估计磁盘I/O占去不少时间。
初步分析以上数据可以得出:
1、 Borland C++ 5.5.1带的STL的性能比较低,而且似乎比较耗内存,在内存较小的机器上执行时,磁盘交换将花去大量时间。
2、 Visual C++ 6.0带的STL,list尚可,但至少deque有问题,很耗内存,结果磁盘交换花去大量时间,可惜我没有256M内存的机器做测试。
3、 GNU C++ 2.95.3带的STL性能较好,在内存较小的机器上执行也没有问题。
4、 精心设计的C程序比实现相同功能且使用STL的C++执行要快。在本次测试中,C++程序的功能主要由STL Container实现,STL的性能影响了整个程序性能的90%以上,所以显出这么大的差距。
下面来搞点移花接木,把GNU C++带的STL给其他两个编译器用看看有什么效果。
在www.sgi.com下载了SGI STL 3.3,在下载时顺便看了看FAQ,得知SGI STL3.3与Visual C++5.0以上搭配时,需要用iostream.h取代iostream;还有是支持SGI STL的编译器里好像没有Borland C++。
把下载来的STL.ZIP释放到C:\Program Files\Microsoft Visual Studio\VC98\Include\SGISTL。并把环境变量重新设置:
set INCLUDE=C:\PROGRA~1\MICROS~3\VC98\INCLUDE\SGISTL;C:\PROGRA~1\MICROS~3\VC98\INCLUDE
然后把markov_l.cpp与markov_d.cpp中的#include<iostream>改为#include<iostream.h>
用cl /G6 /O2 /Og /GX /MT /Fev_d_sgi.exe markov_d.cpp 编译成功,这样又得到两个EXE文件:v_l_sgi.exe与v_d_sgi.exe,前者是markov_l.cpp编译生成的。下面是这两个EXE的平均执行时间:
|
PII 300 with 64M RAM
|
PII 350 with 128M RAM
|
v_l_sgi
|
1.375
|
1.074
|
v_d_sgi
|
1.943
|
1.597
|
哇!比GNU C++本身还要快!当然这个简单的测试并不能证明SGI STL与VC6配合默契,有兴趣的朋友可以进一步测试。
但事情在Borland C++ 5.5.1上就没这么顺利了,我试了好多方法,但程序都不能用SGI STL。有兴趣的朋友可以去www.stlport.org下载STLport 4.5来和Borland C++ 5.5.1配合使用,看看性能如何。
据myan介绍:“Borland使用的是Rogue Wave STL其效率最差;Visual C++中的STL是著名大师P. J. Plauger的个人作品,性能较好,但其queue组件效率很差,慎用。”,这里可以补充一点是VC6的deque效率也很差,慎用。
附记:我是北京师范大学的本科生,写这篇文章时(2001年10月2日)刚上大二,这是我作为一个C++初学者,在学习的过程中的一些心得体会,写在这里供和我一样的初学者参考。
我的信箱:chenshuo@chenshuo.com,个人主页:http://www.chenshuo.com,欢迎访问。
作者主页http://www.chenshuo.com可下载测试文本与源代码
分享到:
相关推荐
纯C语言实现仿C++STL泛型链表,实现了C++STL链表的基本功能,但代码并未做完善的测试,性能也不能保障,主要用于初学者学习
c++标准容器性能测试程序
rbtree一棵红黑树,其API与C ++ STL相似。 带有较少堆对象的高性能红黑树。分期付款 go get -u -v github.com/cdongyang/rbtree测试运行测试: ./test.shcoverage: 95.5% of statements 跑步台: /bin/go test -v -...
LMSTL在原书基础上改写为简单的C ++ 11 STL...关于LMSTL_test.cpp测试各容器和算法的正确性和性能LMSTL_test.cpp检查容器和算法的正确性和性能(当前进度:vector \ map \ list)测试环境Windows10,Visual Studio 2019
stl库的map采用二分查找,性能最差。Google的哈希map性能和内存目前是最优的,但是有重复碰撞的机率。 我在电信行业和信息安全行业里的工作经历发现,目前网络上的哈希算法都在查询速度上远远无法满足日趋增长的网络...
matlab算法,工具源码,适合毕业设计、课程设计作业,所有源码均经过严格测试,可以直接运行,可以放心下载...这些工具可以帮助开发者利用多核处理器和图形处理器(GPU)来加速算法的计算过程,提高算法的性能和效率
STL解析器-基本 目标 打印整个实体的三角形数量和表面积 提供有关如何运行代码的明确说明 讨论更大文件(数百万个方面)的性能改进或方法 讨论代码设计选择的推理 如何运行代码 如果MacOS / Linux => curl -fsSL ...
各种3D打印机性能测试的零件,该零件能打好,说明机器的性能不错。
Electronic Arts Standard Template Library EA的STL基础库,快来膜拜大神…
stl库的map采用二分查找,性能最差。Google的哈希map性能和内存目前是最优的。 我在电信行业和信息安全行业里的工作经历发现,目前网络上的哈希算法都在查询速度上远远无法满足日趋增长的网络大数据要求。因此产生...
stl库的map采用二分查找,性能最差。Google的哈希map性能和内存目前是最优的,但是有重复碰撞的机率。现在大数据 基本上不用有碰撞 几率的map。 现在我把pwwMap算法发布出来。大家可以测试对比发现,我的算法属于零...
stl库的map采用二分查找,性能最差。Google的哈希map性能和内存目前是最优的。 我在电信行业和信息安全行业里的工作经历发现,目前网络上的哈希算法都在查询速度上远远无法满足日趋增长的网络大数据要求。因此产生了...
思博伦与STL Partners携手合作,通过现实世界的边缘网络测试和针对潜在边缘客户开展的150余项调研,成功弥合了这条信息鸿沟。我们的基准测试分析提供了诸多深入的见解,包括对MEC性能测量最为重要的项目、通过如今的...
用表面热透镜(STL)技术测量了样品的弱吸收值;用调Q脉冲激光装置测试了样品的抗激光损伤阈值(LIDT)。实验结果发现,样品的实验光谱性能与理论光谱性能有很好的一致性,退火前后其光谱性能几乎没有发生温漂,说明薄膜的...
3. STL容器的内存分配 ## 数据库连接 数据库连接是c++服务器开发中必不可少的一部分。数据存储和访问是服务器的重要功能之一。数据库连接基础包括以下内容: 1. MySQL数据库连接 2. 数据库连接池技术 3. 数据库O
它包含有用的基础类的集合,这些基础类很好地补充了STL。 主要特点: 专为高性能,多线程生产环境而设计 高容量服务器开发的通用组件 充分利用无锁技术 使用C ++ 11所拥有的内容,并专注于C ++ 11所缺乏的内容 ...
简历包括专业技能,项目经历等,熟悉 C++编程语言,熟悉 STL 下常见容器底层数据结构,了解 Python、SQL 等; 熟悉常见数据结构及算法,如十大排序(快速排序、归并排序、堆排序等); 熟悉 OSI 七层模型,掌握 ...
它的性能可与 strlen() 相比。可支持 SSE2/SSE4.2 加速。 RapidJSON 独立。它不依赖于 BOOST 等外部库。它甚至不依赖于 STL。 RapidJSON 对内存友好。在大部分 32/64 位机器上,每个 JSON 值只占 16 字节(除字符串外)...
它支持 UTF-8、UTF-16、UTF-32 (大端序/小端序),并内部支持这些编码的检测、校验及转码。例如,RapidJSON 可以在分析一个 UTF-8 文件至 DOM 时,把当中的 JSON 字符串转码至 UTF-16。它也支持代理对(surrogate ...