Coremark
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
CoreMark is a benchmark that measures the performance of central processing units (CPU) used in embedded systems. It was developed in 2009[1] by Shay Gal-On at EEMBC and is intended to become an industry standard, replacing the Dhrystone benchmark.[2] The code is written in C and contains implementations of the following algorithms: list processing (find and sort), matrix manipulation (common matrix operations), state machine (determine if an input stream contains valid numbers), and CRC. The code is under the Apache License 2.0 and is free of cost to use, but ownership is retained by the Consortium and publication of modified versions under the CoreMark name prohibited.[3]
Issues addressed by CoreMark
[edit]The CRC algorithm serves a dual function; it provides a workload commonly seen in embedded applications and ensures correct operation of the CoreMark benchmark, essentially providing a self-checking mechanism. Specifically, to verify correct operation, a 16-bit CRC is performed on the data contained in elements of the linked list.
To ensure compilers cannot pre-compute the results at compile time every operation in the benchmark derives a value that is not available at compile time. Furthermore, all code used within the timed portion of the benchmark is part of the benchmark itself (no library calls).
CoreMark versus Dhrystone
[edit]CoreMark draws on the strengths that made Dhrystone so resilient - it is small, portable, easy to understand, free, and displays a single number benchmark score. Unlike Dhrystone, CoreMark has specific run and reporting rules, and was designed to avoid the well understood issues that have been cited with Dhrystone.
Major portions of Dhrystone are susceptible to a compiler’s ability to optimize the work away; thus it is more a compiler benchmark than a hardware benchmark. This also makes it very difficult to compare results when different compilers/flags are used.
Library calls are made within the timed portion of Dhrystone. Typically, those library calls consume the majority of the time consumed by the benchmark. Since the library code is not part of the benchmark, it is difficult to compare results if different libraries are used. Guidelines exist on how to run Dhrystone but since results are not certified or verified, they are not enforced.[citation needed] There is no standardization on how Dhrystone results should be reported, with various formats in use (DMIPS, Dhrystones per second, DMIPS/MHz)
Results
[edit]CoreMark results can be found on the CoreMark web site,[4] and on processor data sheets. Results are in the following format:
CoreMark 1.0 : N / C / P / M
- N Number of iterations per second (with seeds 0,0,0x66,size=2000)
- C Compiler version and flags
- P Parameters such as data and code allocation specifics
- M – Type of Parallel algorithm execution (if used) and number of contexts
For example: CoreMark 1.0 : 128 / GCC 4.1.2 -O2 -fprofile-use / Heap in TCRAM / FORK:2
See also
[edit]- Business Applications Performance Corporation (BAPCo)
- Embedded Microprocessor Benchmark Consortium (EEMBC)
- Standard Performance Evaluation Corporation (SPEC)
- Transaction Processing Performance Council (TPC)
References
[edit]- ^ Pitcher, Graham (2009-06-08). "EEMBC launches MIPS busting benchmark". newelectronics.co.uk. Retrieved 2020-04-28.
- ^ "ARM Announces Support For EEMBC CoreMark Benchmark". GISCafe. 2009-06-06. Retrieved 2020-04-28.
- ^ "COREMARK® ACCEPTABLE USE AGREEMENT". GitHub. 2018-05-24. Retrieved 2020-04-28.
- ^ "Scores". Coremark. Retrieved 2020-04-28.