Quoting original author of this patch: Simply un-limits the 'misc' and 'system' suites. Half-related thoughts about testing quality: I'm curious why there's a shell1, shell8, and shell16 set of tests. Aren't the latter two equivalent to './Run -c 8 shell1' and './Run -c 16 shell1'? I think shell8 and shell16 are pointless if this is the case. At the very least, I think shell8 should be out of the default run (the $index set), because it will essentially give a misleading number if you have more than a single core in the system. Isn't the purpose of the serial run to essentially measure how well the system performs on single-threaded activities? Or perhaps to measure how well a single core performs? Having 'shell8' in the $index set artificially inflates the score for serialized runs and artificially damages the score during maxed-out parallelized runs. If you are actually interested in seeing how well 'shell8' does on exactly one core, shouldn't you do the equivalent of 'taskset 1' on it, forcing the child processes to stay on that single core? End of quote. Signed-off-by: Carlos L. Torres <carlos.torres@rackspace.com> |
||
---|---|---|
UnixBench | ||
README.md |
byte-unixbench
UnixBench is the original BYTE UNIX benchmark suite, updated and revised by many people over the years.
The purpose of UnixBench is to provide a basic indicator of the performance of a Unix-like system; hence, multiple tests are used to test various aspects of the system's performance. These test results are then compared to the scores from a baseline system to produce an index value, which is generally easier to handle than the raw scores. The entire set of index values is then combined to make an overall index for the system.
Some very simple graphics tests are included to measure the 2D and 3D graphics performance of the system.
Multi-CPU systems are handled. If your system has multiple CPUs, the default behaviour is to run the selected tests twice -- once with one copy of each test program running at a time, and once with N copies, where N is the number of CPUs. This is designed to allow you to assess:
- the performance of your system when running a single task
- the performance of your system when running multiple tasks
- the gain from your system's implementation of parallel processing
History
UnixBench was first started in 1983 at Monash University, as a simple synthetic benchmarking application. It was then taken and expanded by Byte Magazine. Linux mods by Jon Tombs, and original authors Ben Smith, Rick Grehan, and Tom Yager. The tests compare Unix systems by comparing their results to a set of scores set by running the code on a benchmark system, which is a SPARCstation 20-61 (rated at 10.0).David C. Niemi maintained the program for quite some time, and made some major modifications and updates, and produced UnixBench 4. He later gave the program to Ian Smith to maintain. Ian subsequently made some major changes and revised it from version 4 to version 5.
Thanks to Ian Smith for managing the release up to 5.1.3. As of the next release (5.2) Anthony F. Voellm is going to help maintain the code base. The releases will happen once there are enough pull requests to warrent a new release.
The general process will be the following:
- Open a bug annoucing a new release will happen.
- Everything of the dev branch will be run.
- Code will move from the dev branch into main and be tagged. Bug fix releases with increment the subversion and major functionality changes will increase the major version.