很多用户使用UnixBench进行性能测试，进行制造商之间的比较。 UnixBench进行了什么样的性能测试，本篇从代码层面阐述了UnixBench进行了什么样的测试。
在详细说明UnixBench的实现之前，先放一个总结果UnixBench的计算点介绍有类似的结果，然后逐一说明。 从结果可以看出，结果分为两个块。 一个是单进程，另一个是多进程。 默认情况下，多进程的数量取决于CPU数量。 多进程测试只是增加了进程数，而内存实际上与单进程相同，因此以下所有说明都适用于单进程。
Dhrystone2usingregistervariables这里有比较详细的dhrystone介绍。 它主要测量整数的性能，相应的浮点数测试是双精度微单。
对不起，说得很拙劣，但我不知道那个运算会怎么样，所以在网上搜索了很多文章。 其宗旨是通过编译优化提高性能，无法真实地反映CPU的性能。 这篇文章具有典型的意义。 是benchmarkingincontext : dhrystone。
请绕过其中的一块计算，说出输出。 默认值在10秒以内。 那一块计算可以计算次数。 计算分数后，参考上一篇UnixBench计算点的介绍，计算索引分数。
Double-Precision Whetstone既有整数运算的CPU性能，也想要浮点运算性能。 whets.c的代码质量一直很高，我终于读了。
需要得到适当的参数。 怎么得到这个运算呢？ 存在坤运算，随着输入参数(xtra )增大，时间逐渐增减，时间超过2秒时参数不会增大。
跑10秒的话，大致的参数会怎么样？ 625*10/1.238352=5047根据输入参数计算结果。 我之前没说，那计算是什么？ 一共分为八个步骤。 英语说明还很清楚，采用了浮点数的分数。 但是那个时间怎么其他计算时间都在开心地跳舞。 明明只关心浮点数的运算，为什么要加N3？
Execl Throughput除了上述两个之外都很复杂，UnixBench的其他运算比较简单，Execl实际上是递归调用，主要利用的是Execl函数。 编译自身execl.c的可执行文件是execl的二进制文件，运行execl函数时需要参数：开始时间、执行次数、时间(通常为10秒)。 这次总执行时间超过10秒的情况下，输出执行次数，根据计算点规则计算点的思想还是很巧妙的。
使用主要是测试write和read两个函数(File Copy )测试30秒钟。 实现简单，首先对一个文件写入(循环写入) 2秒钟，重读2秒钟，然后从刚写入的文件读取数据，写入另一个文件，进行循环写入，以30秒的读写次数进行。 建议使用不同的参数测量不同块大小、不同块数的性能，在测试磁盘时使用FIO进行测试。
Pipe Throughput打开管道，向管道写入、读取、测试512个字节，测试10秒钟，总读写次数
基于管道的上下文交换打开两个管道，打开两个进程。 一个进程写入管道1，读取到管道2，另一个进程写入管道2，读取到管道2，一个进程完成一次读写，计数为1。 有趣的是，如果这两个进程在同一CPU和不同CPU上具有完全不同的性能，则在同一CPU上性能会更好。 这里有详细的分析，值得评估： Unixbench测试套件的缺陷深度分析
处理创建是指继续调用fork函数，创建进程，立即退出，并成功计数一次。
shell脚本通过fork函数，创建流程，不断运行一个脚本，成功运行一次1.shell脚本一个并发就是传递给脚本(pgms/mullent )
System Call Overhead想计算离开操作系统的开销，所以离开后进入计数1，对10秒内的执行次数进行计数。 实际执行的效果在fork子进程、waitpid函数之后结束，并计数为1
上面介绍了UnixBench的缺省实现，简单但有趣！