 | This article has multiple issues. Please helpimprove it or discuss these issues on thetalk page.(Learn how and when to remove these messages) (Learn how and when to remove this message)
|
CoreMark is abenchmark that measures the performance ofcentral processing units (CPU) used inembedded systems. It was developed in 2009[1] by Shay Gal-On atEEMBC and is intended to become an industry standard, replacing theDhrystone benchmark.[2] The code is written inC 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), andCRC. 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]
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 thelinked 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 (nolibrary calls).
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 withDhrystone.
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)
Source code for, and instructions for running, both the original CoreMark benchmark and the CoreMark-PRO benchmark are available on GitHub.[4][5]
The tests in the original CoreMark benchmark are intended to run on a wide range of processors from 8-bit microcontrollers to 64-bit microprocessors,and focuses on single-threaded integer processor performance, with support for testing parallel threads.[6]
The CoreMark-PRO benchmark is intended to run on a much narrower range of 32-bit to 64-bit processors, and includes larger data sets for stress-testing larger memory subsystems, tests for floating-point performance, and tests for parallel-processing performance.[6]
While both CoreMark and CoreMark-PRO can be run "bare metal", they are also often run on machines with an operating system, such as with thePhoronix Test Suite.[7]
CoreMark results can be found on the CoreMark web site,[8] and on processor data sheets. Results are in the following format:
CoreMark 1.0 : N / C / P / M
For example: CoreMark 1.0 : 128 / GCC 4.1.2 -O2 -fprofile-use / Heap in TCRAM / FORK:2
