关于基准测试
由于现在有非常多种的计算机系统在同事使用,在选择计算机时用户总是希望比较一下究竟哪个系统更适合自己的需要(在早期计算机运算能力不强的时候,用户一般总是选择速度更快的计算机。因为那个时候总是有无数的任务等待计算机执行,只要计算机越快,就能够完成更多的工作,越能够满足用户的需求。所以,这种观点一直延续至今)。用户总是希望得到唯一一个反映计算机系统对自己的需求的满意程度的指数,他们只要选择指数最大或最小的系统。这样的指数当然是非常完美的,但是很难实现。某些方面的性质无法量化和加权,甚至测试也是很困难的(比如:稳定性)。于是用户退而求其次,要求一个能够反映计算机运行速度的指数。这就是基准测试的由来。很早的时候就有了基准测试程序,通过这些年的发展已经相对比较完善,并有了一系列的理论支持。而且,基准测试不仅仅提供了计算机系统间相互比较的标准,还为计算机系统的改进、新系统的设计提供了重要信息一依据。
当然基准测试程序是很难编写的。理想情况是把用户需要运行的程序全部运行一次,计算完成时间。这通常是办不到的。而且不同的用户有不同的应用,其运行的程序也不同。所以随着计算机系统越来越普及,基准测试程序也出现了各种分支,分别满足不同方面的用户的测试需求。
在真正讨论基准测试程序之前,我想先讨论一下现阶段哪些方面需要进行基准测试。
上面已经说过,基准测试是给出一个反映系统运行某方面程序的速度的指标。所以,只有当用户关心这方面的程序的运行速度的时候,基准测试才是有必要的。换句话说,只有当用户对计算机的速度“不满意”的时候,基准测试才有意义。很多测试程序花很大的力气测试OFFICE的运行速度,真是不知道他们想说明什么问题。要知道OFFICE在486上就运行得很流畅了,谁会关心键盘上敲进去的一个字母是5ms后出现在屏幕上还是10ms后出现在屏幕上?现在的计算机系统对这方面的应用已经足够了,完全没有必要考虑。如果OFFICE在你的电脑上跑得太慢,是因为M$在里面加入了所谓的智能而其实毫无疑义的功能而你又没有禁止它们运行。所以,需要进行基准测试的应用,应该是实实在在的计算量很大的应用。
科学计算是一类计算量巨大的应用。看看世界各国竞相开发计算能力惊人的巨型机就可以知道其计算量的巨大。在这方面,SPEC是公认的比较完善的基准测试。在这方面,理论和实践都比较丰富,这里就不详细讨论了。
在日常使用中,要涉及到科学计算的情况还是比较少的。在日常应用中,游戏和多媒体程序是计算量巨大的应用,现有的计算机系统还不能做到应付自如。所以这方面性能也是多数用户关注的焦点。
如果仔细研究这些程序的特点,可以发现它们的计算量主要集中在这些方面:(1)3D运算。这是一大类真正繁重的运算,包括整数、浮点等各种复杂的操作。不过现在的显示卡已经集成了大量的部件来处理这方面的运算,CPU在这方面的负担减轻了很多。这方面也有很多好的基准测试程序,这里也不想多说。(2)传统的AI运算。在游戏中一般都有大量的决策运算来实现人机对抗等等功能。这些运算可以划归为传统人工智能运算。其运算特点是大量复杂数据结构上的查找操作、字符串运算等,而且算法一般是NP完全的,其计算量之巨大不可能通过计算机的计算能力解决。这一类运算还有很大的不确定性,导致支出的计算量的稍微变化不会对结果有显著的影响。也就是说,即使某个参与竞争的计算机系统比另一个稍快,也很有可能得出的最终结果没有变化甚至还要差。这样,也没有太大的必要关心不同系统间计算能力的些微差异。(3)多媒体运算,包括视频、声音、图象、文字等的编码解码、分析处理、显示转换等。这是一大类真正计算量巨大的运算,并且和各种程序都有很大的关系。随着用户对软件的要求的提高,越来越多的软件加入多媒体运算来取悦苛刻的用户,使其不仅仅在游戏和娱乐方面有应用。比如,现在很多程序都试图集成语音识别技术。而语音识别技术的运算量相对还是比较大的,现在正在使用的很多计算机系统都无法达到实时识别。而众多用户期望的视频电话等暂时还必须要有专门的硬件辅助才能实现。
这里想要讨论的问题,将集中于现有计算机系统和多媒体运算的关系上,也就是说,现有计算机系统的设计哪些有利于多媒体运算的实现,哪些对其不利。至于系统间的差异、性能基准参数等,不在主要讨论之列。
在进入测试的讨论之前,必须要知道多媒体运算本身的特点。否则其测试将毫无意义。具体来说,多媒体运算的特点如下:
根据这些特点,计算机系统必须要有针对性地提供功能才能快速地运行这些程序。概括来说,计算机系统应该具有如下的功能:
所以,一个完备的测试程序必须对这些方面都要有适当的反映。这将是一个非常庞大的工程。本站在第一阶段将主要关心内存、CACHE和CPU之间的数据传递上,包括不同访问顺序、不同访问方式下的访问速度,各个内存层次的物理和性能参数等都在讨论之列。另外,由于多媒体程序核心代码很小,这里主要考虑计算机系统中有关数据的通道和部件,如L1 D-Cache等。后面的测试一般假设代码可以全部放到L1 I-Cache中。这可能和实际情况有些差距,但在主要考虑数据通道的情况下,代码的影响最小,可以得到比较准确的测试值。
附录:多路顺序访问
多媒体数据通常是多维的,而普通数据通常是一维的。例如,一般用二维数组表示一幅图象,则图象数据是二维的。而视频数据可以类推得知是三维的。虽然严格意义的语音数据是一维的,但是如果考虑多声道的情况,也可以认为声音是二维的。对于文本数据,很多时候则会被表示成更高的维数(在研究领域甚至可达千维、万维)。二多媒体数据总量巨大的特点,又决定了多媒体数据在磁盘上的存储格式通常是高度压缩的。我们平时接触的VCD是MPEG1格式的视频/音频文件,DVD是MPEG1格式的,歌曲则常用MP3格式。这些格式都是压缩比非常高的格式。一般情况下,VCD的平均压缩率约30~100倍,DVD约20~50倍,MP3约5~10倍(当然,要达到在现在的Internet上有满意的表现,一般认为视频压缩率应达到1000~5000。这是现在很多多媒体研究机构的目标)。要达到如此高的压缩率,必须要以适当的顺序组织数据。一般认为,“相邻”的数据有很大的相似性,再根据信息论的原理,如果把它们放到一起,就可以达到更高的压缩比(这里的细节已经超出本站讨论范围。更详细情况可以参考信息论方面的专业书籍)。这里的“相邻”是一个简单的概念,只要二点在所有维上的坐标都相近,就认为次二点“相邻”。虽然概念简单,但造成的问题却不小。请看下图:
Line 1 | |||||||||||
Line 2 | |||||||||||
Line 3 | |||||||||||
Line 4 | |||||||||||
Line 5 |
如果这是一幅图象,其中每个方块代表一个像素,则中心红色像素的相邻像素是周围的8个绿色方块。在多媒体处理中,为了达到高压缩比,就要把这9个像素放到一起考虑。于是,这个处理一共涉及到图象中的三行。在这9个像素处理完后,很自然地接着处理黄色方块的9个像素。如此循环往复,就是多媒体处理中的基本数据组织方式。如果图象按通常的行方式存放,则在上面的例子中,可以认为数据的访问方式为“3个同时进行的顺序访问”。这就是多媒体处理中最常用的数据访问方式。当然,真正的处理程序中,过程要复杂一些。一般情况下,处理过程以8×8或16×16为单位进行。而彩色图象有三个颜色分量,所以一般处理单幅图象的过程同时有8×3=24或16×3=48路同时进行的顺序访问(大多数图象处理程序用一种叫做YUV420的YUV格式表示颜色,在以16×16为单位的过程中同时仅有32路顺序访问)。而视频数据通常涉及到相邻的3帧,其路数要再乘3。可见,同时进行的顺序访问路数是很大的。这给硬件和软件设计带来了极大的挑战。