| Benchmark (computing) |
Article Index for Benchmark |
Information AboutBenchmark (computing) |
|
In Computing , a benchmark is the result of running a Computer Program , or a set of programs, in order to assess the relative performance of an object, by running a number of standard tests and trials against it. The term, benchmark, is also commonly used for specially-designed benchmarking programs themselves. Benchmarking is usually associated with assessing performance characteristics of computer hardware, for example, the floating point operation performance of a CPU , but there are circumstances when the technique is also applicable to software. Software benchmarks are, for example, run against Compilers or Database Management System s. Benchmarks provide a method of comparing the performance of various subsystems across different chip/system architectures. PURPOSE As Computer Architecture advanced, it became more and more difficult to compare the performance of various computer systems simply by looking at their specifications. Therefore, tests were developed that could be performed on different systems, allowing the results from these tests to be compared across different architectures. For example, Intel Pentium 4 processors have a higher hertz rating than AMD Athlon XP processors for the same computational speed, in other words a 'slower' AMD processors could be as fast on benchmark tests as a higher hertz rated Intel processors. 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, instead, run actual real-world programs on the system. Whilst application benchmarks usually give a much better measure of real-world performance on a given system, synthetic benchmarks still have their use for testing out individual components, like a Hard Disk or networking device. Benchmarks are particularly important in Semiconductor Microprocessor design, giving processor architects the ability to measure and make tradeoffs in Microarchitectural decisions. For example, if a benchmark extracts the key Algorithms 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 used is unique in that its benchmark scores and benchmark reports must be certified by the consortium's EEMBC Technology Center before they can be published. EEMBC's next great challenge is benchmarking power consumption and energy utilization by processors as more and more embedded processors go into low-power environments such as Cellular Phones and other mobile applications. Computer manufacturers have a long history of trying to set up their systems to give unrealistically high performance on benchmark tests that is 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 mathematically-equivalent operation that was much faster. However, such a transformation was rarely useful outside the benchmark until the mid-1990s, when RISC and VLIW architectures emphasized the importance of Compiler technology as it related to performance. Benchmarks are now regularly used by Compiler companies to improve not only their own benchmark scores, but real application performance. Manufacturers 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. Taken together, these practices are called ''bench-marketing.'' See this article for an excellent example of how application benchmarks can differ significantly from synthetic benchmarks. Users are recommended to take benchmarks, particularly those provided by manufacturers themselves, with ample quantities of salt unless the benchmarks are certified and relate directly to a recognizable application workload. 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 really critical, the only benchmark that matters is the actual workload that the system is to be used for. If that is not possible, benchmarks that resemble real workloads as closely as possible should be used, and even then used with skepticism unless independently certified. It is quite possible for system A to outperform system B when running program "furble" on workload X (the workload in the benchmark), and the order to be reversed with the same program on your own workload. CHALLENGES 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:
TYPES OF BENCHMARKS #Real program
#Kernel
#Toy Benchmark
#Synthetic Benchmark
# I/O benchmarks # Parallel benchmarks: used on machines with multiple processors or systems consisting of multiple machines. COMMON BENCHMARKS
Open source benchmarks
Microsoft Windows benchmarks
SEE ALSO
EXTERNAL LINKS
|
|
|