首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    unixbench详解

    unixbench是一套unix系统基准测试套件。unixbench的设计目标是为类unix系统提供一套基本的指标,所以有许多项目测试系统各方面的性能。各项的测试有得分,然后有一个综合的得分,这样可以很方便的通过分数去比较。 unixbench也包含一些非常简单的2D和3D图形测试。 unixbench也支持多CPU系统的测试,默认的行为是测试两次,第一次是一个进程的测试,第二次是N份测试,N等于CPU个数。这样的设计是为了以下目标: 测试系统的单任务性能 测试系统的多任务性能 测试系统并行处理的能力 unixbench一个基于系统的基准测试工具,不单纯是CPU 内存 或者磁盘测试工具。测试结果不仅仅取决于硬件,也取决于系统、开发库、甚至是编译器。 测试项目 Dhrystone测试 测试聚焦在字符串处理,没有浮点运算操作。这个测试用于测试链接器编译、代码优化、内存缓存、等待状态、整数数据类型等,硬件和软件设计都会非常大的影响测试结果。 Whetstone 测试 这项测试项目用于测试浮点运算效率和速度。这项测试项目包含若干个科学计算的典型性能模块,包含大量的C语言函数,sin cos sqrt exp和日志以及使用整数和浮点的数学操作。包含数组访问、条件分支和过程调用。 Execl Throughput(execl 吞吐,这里的execl是类unix系统非常重要的函数,非办公软件的execl)测试 这项测试测试每秒execl函数调用次数。execl是 exec函数家族的一部分,使用新的图形处理代替当前的图形处理。有许多命令和前端的execve()函数命令非常相似。 File Copy测试 这项测试衡量文件数据从一个文件被传输到另外一个,使用大量的缓存。包括文件的读、写、复制测试,测试指标是一定时间内(默认是10秒)被重写、读、复制的字符数量。 Pipe Throughput(管道吞吐)测试 pipe是简单的进程之间的通讯。管道吞吐测试是测试在一秒钟一个进程写512比特到一个管道中并且读回来的次 数。管道吞吐测试和实际编程有差距。 Pipe-based Context Switching (基于管道的上下文交互)测试 这项测试衡量两个进程通过管道交换和整数倍的增加吞吐的次数。基于管道的上下文切换和真实程序很类似。测试程序产生一个双向管道通讯的子线程。 Process Creation(进程创建)测试 这项测试衡量一个进程能产生子线程并且立即退出的次数。新进程真的创建进程阻塞和内存占用,所以测试程序直接使用内存带宽。这项测试用于典型的比较大量的操作系统进程创建操作。 Shell Scripts测试 shell脚本测试用于衡量在一分钟内,一个进程可以启动并停止shell脚本的次数,通常会测试1,2, 3, 4, 8 个shell脚本的共同拷贝,shell脚本是一套转化数据文件的脚本。 System Call Overhead (系统调用消耗)测试 这项测试衡量进入和离开系统内核的消耗,例如,系统调用的消耗。程序简单重复的执行getpid调用(返回调用的进程id)。消耗的指标是调用进入和离开内核的执行时间。 Graphical Tests(图形)测试 由"ubgears"程序组成,测试非常粗的2D和3D图形性能,尤其是3D测试非常有限。测试结果和硬件,系统合适的驱动关系很大。 unixbench安装

    03

    编写Shell脚本的最佳实践

    由于工作需要,最近重新开始拾掇shell脚本。虽然绝大部分命令自己平时也经常使用,但是在写成脚本的时候总觉得写的很难看。而且当我在看其他人写的脚本的时候,总觉得难以阅读。毕竟shell脚本这个东西不算是正经的编程语言,他更像是一个工具,用来杂糅不同的程序供我们调用。因此很多人在写的时候也是想到哪里写到哪里,基本上都像是一段超长的main函数,不忍直视。同时,由于历史原因,shell有很多不同的版本,而且也有很多有相同功能的命令需要我们进行取舍,以至于代码的规范很难统一。 考虑到上面的这些原因,我查阅了一些相关的文档,发现这些问题其实很多人都考虑过,而且也形成了一些不错的文章,但是还是有点零散。因此我就在这里把这些文章稍微整理了一下,作为以后我自己写脚本的技术规范。

    01

    编写Linux Shell脚本的最佳实践

    由于工作需要,最近重新开始拾掇shell脚本。虽然绝大部分命令自己平时也经常使用,但是在写成脚本的时候总觉得写的很难看。而且当我在看其他人写的脚本的时候,总觉得难以阅读。毕竟shell脚本这个东西不算是正经的编程语言,他更像是一个工具,用来杂糅不同的程序供我们调用。因此很多人在写的时候也是想到哪里写到哪里,基本上都像是一段超长的main函数,不忍直视。同时,由于历史原因,shell有很多不同的版本,而且也有很多有相同功能的命令需要我们进行取舍,以至于代码的规范很难统一。 考虑到上面的这些原因,我查阅了一些相关的文档,发现这些问题其实很多人都考虑过,而且也形成了一些不错的文章,但是还是有点零散。因此我就在这里把这些文章稍微整理了一下,作为以后我自己写脚本的技术规范。

    03
    领券