This articleneeds attention from an expert in computer science. The specific problem is:Outdated or deprecated sources. See thetalk page for details.WikiProject Computer science may be able to help recruit an expert.(October 2022)
A graphical demo running as a benchmark of theOGRE engine
Incomputing, abenchmark is the act of running acomputer program, a set of programs, or other operations, in order to assess the relativeperformance of an object, normally by running a number of standardtests and trials against it.[1]
The termbenchmark is also commonly utilized for the purposes of elaborately designed benchmarking programs themselves.
Benchmarks provide a method of comparing the performance of various subsystems across different chip/systemarchitectures. Benchmarking as a part ofcontinuous integration is called Continuous Benchmarking.[2]
Ascomputer architecture advanced, it became more difficult to compare the performance of various computer systems simply by looking at their specifications. Therefore, tests were developed that allowed comparison of different architectures. For example,Pentium 4 processors generally operated at a higher clock frequency thanAthlon XP orPowerPC processors, which did not necessarily translate to more computational power; a processor with a slower clock frequency might perform as well as or even better than a processor operating at a higher frequency. SeeBogoMips and themegahertz myth.
Benchmarks are designed to mimic a particular type of workload on a component or system. Synthetic benchmarks do this by specially created programs that impose the workload on the component. Application benchmarks run real-world programs on the system. While application benchmarks usually give a much better measure of real-world performance on a given system, synthetic benchmarks are useful for testing individual components, like ahard disk or networking device.
Benchmarks are particularly important inCPU design, giving processor architects the ability to measure and make tradeoffs inmicroarchitectural decisions. For example, if a benchmark extracts the keyalgorithms of an application, it will contain the performance-sensitive aspects of that application. Running this much smaller snippet on a cycle-accurate simulator can give clues on how to improve performance.
Prior to 2000, computer and microprocessor architects usedSPEC to do this, although SPEC's Unix-based benchmarks were quite lengthy and thus unwieldy to use intact.
Computer companies are known to configure their systems to give unrealistically high performance on benchmark tests that are not replicated in real usage. For instance, during the 1980s some compilers could detect a specific mathematical operation used in a well-known floating-point benchmark and replace the operation with a faster mathematically equivalent operation. However, such a transformation was rarely useful outside the benchmark until the mid-1990s, whenRISC andVLIW architectures emphasized the importance ofcompiler technology as it related to performance. Benchmarks are now regularly used bycompiler companies to improve not only their own benchmark scores, but real application performance.
CPUs that have many execution units — such as asuperscalar CPU, aVLIW CPU, or areconfigurable computing CPU — typically have slower clock rates than a sequential CPU with one or two execution units when built from transistors that are just as fast. Nevertheless, CPUs with many execution units often complete real-world and benchmark tasks in less time than the supposedly faster high-clock-rate CPU.
Given the large number of benchmarks available, a vendor can usually find at least one benchmark that shows its system will outperform another system; the other systems can be shown to excel with a different benchmark.
Software vendors also use benchmarks in their marketing, such as the "benchmark wars" between rivalrelational database makers in the 1980s and 1990s. Companies commonly report only those benchmarks (or aspects of benchmarks) that show their products in the best light. They also have been known to mis-represent the significance of benchmarks, again to show their products in the best possible light.[3][4]
Ideally benchmarks should only substitute for real applications if the application is unavailable, or too difficult or costly to port to a specific processor or computer system. If performance is critical, the only benchmark that matters is the target environment's application suite.
Features of benchmarking software may include recording/exporting the course of performance to aspreadsheet file, visualization such as drawingline graphs orcolor-coded tiles, and pausing the process to be able to resume without having to start over. Software can have additional features specific to its purpose, for example, disk benchmarking software may be able to optionally start measuring the disk speed within a specified range of the disk rather than the full disk, measurerandom access reading speed andlatency, have a "quick scan" feature which measures the speed through samples of specified intervals and sizes, and allow specifying adata block size, meaning the number of requested bytes per read request.[5]
Benchmarking is not easy and often involves several iterative rounds in order to arrive at predictable, useful conclusions. Interpretation of benchmarking data is also extraordinarily difficult. Here is a partial list of common challenges:
Vendors tend to tune their products specifically for industry-standard benchmarks. Norton SysInfo (SI) is particularly easy to tune for, since it mainly biased toward the speed of multiple operations. Use extreme caution in interpreting such results.
Some vendors have been accused of "cheating" at benchmarks — designing their systems such that they give much higher benchmark numbers, but are not as effective at the actual likely workload.[6]
Many benchmarks focus entirely on the speed ofcomputational performance, neglecting other important features of a computer system, such as:
Qualities of service, aside from raw performance. Examples of unmeasured qualities of service include security, availability, reliability, execution integrity, serviceability, scalability (especially the ability to quickly and nondisruptively add or reallocate capacity), etc. There are often real trade-offs between and among these qualities of service, and all are important in business computing.Transaction Processing Performance Council Benchmark specifications partially address these concerns by specifyingACID property tests, database scalability rules, and service level requirements.
In general, benchmarks do not measureTotal cost of ownership. Transaction Processing Performance Council Benchmark specifications partially address this concern by specifying that a price/performance metric must be reported in addition to a raw performance metric, using a simplifiedTCO formula. However, the costs are necessarily only partial, and vendors have been known to price specifically (and only) for the benchmark, designing a highly specific "benchmark special" configuration with an artificially low price. Even a tiny deviation from the benchmark package results in a much higher price in real world experience.
Facilities burden (space, power, and cooling). When more power is used, a portable system will have a shorter battery life and require recharging more often. A server that consumes more power and/or space may not be able to fit within existing data center resource constraints, including cooling limitations. There are real trade-offs as most semiconductors require more power to switch faster. See alsoperformance per watt.
In some embedded systems, where memory is a significant cost, bettercode density can significantly reduce costs.
Vendor benchmarks tend to ignore requirements for development, test, anddisaster recovery computing capacity. Vendors only like to report what might be narrowly required for production capacity in order to make their initial acquisition price seem as low as possible.
Benchmarks are having trouble adapting to widely distributed servers, particularly those with extra sensitivity to network topologies. The emergence ofgrid computing, in particular, complicates benchmarking since some workloads are "grid friendly", while others are not.
Users can have very different perceptions of performance than benchmarks may suggest. In particular, users appreciate predictability — servers that always meet or exceedservice level agreements. Benchmarks tend to emphasize mean scores (IT perspective), rather than maximum worst-case response times (real-time computing perspective), or low standard deviations (user perspective).
Many server architectures degrade dramatically at high (near 100%) levels of usage — "fall off a cliff" — and benchmarks should (but often do not) take that factor into account. Vendors, in particular, tend to publish server benchmarks at continuous at about 80% usage — an unrealistic situation — and do not document what happens to the overall system when demand spikes beyond that level.
Many benchmarks focus on one application, or even one application tier, to the exclusion of other applications. Most data centers are now implementingvirtualization extensively for a variety of reasons, and benchmarking is still catching up to that reality where multiple applications and application tiers are concurrently running on consolidated servers.
There are few (if any) high quality benchmarks that help measure the performance of batch computing, especially high volume concurrent batch and online computing.Batch computing tends to be much more focused on the predictability of completing long-running tasks correctly before deadlines, such as end of month or end of fiscal year. Many important core business processes are batch-oriented and probably always will be, such as billing.
Benchmarking institutions often disregard or do not follow basic scientific method. This includes, but is not limited to: small sample size, lack of variable control, and the limited repeatability of results.[7]
AIM Multiuser Benchmark – composed of a list of tests that could be mixed to create a 'load mix' that would simulate a specific computer function on any UNIX-type OS.
BRL-CAD – cross-platform architecture-agnostic benchmark suite based on multithreaded ray tracing performance; baselined against a VAX-11/780; and used since 1984 for evaluating relative CPU performance, compiler differences, optimization levels, coherency, architecture differences, and operating system differences.
Collective Knowledge – customizable, cross-platform framework to crowdsource benchmarking and optimization of user workloads (such asdeep learning) across hardware provided by volunteers
NBench – synthetic benchmark suite measuring performance of integer arithmetic, memory operations, and floating-point arithmetic
PAL – a benchmark for realtime physics engines
PerfKitBenchmarker – A set of benchmarks to measure and compare cloud offerings.
Phoronix Test Suite – open-source cross-platform benchmarking suite for Linux, OpenSolaris, FreeBSD, OSX and Windows. It includes a number of other benchmarks included on this page to simplify execution.
