Recently Van Smith of Canalabs submitted several scores to the CoreMark website. We asked him about his choices for run parameters…
[NOTE: To put this blog into context, refer to the scores submitted on April 12 for Intel Atom N450, VIA Nano L3050, AMD Mobile Athlon XP-M (Barton), and Freescale i.MX515 at http://coremark.org/benchmark/index.php?pg=benchmark)
Why did you use FORK rather then PTHREADS?
Answer: I used the same set of CoreMark compiler flags and settings as I had come up with several months ago after experimenting on an AMD Phenom II system. However, these settings came directly from the best performing Intel system on CoreMark website. Of course, forking is the most reliable way of getting multicore scaling across a broad range of platforms, which is my goal. Threading can lead to headaches in those situations.
*NOTE from Shay Gal-On: CoreMark actually contains 3 separate methods to use concurrency. All of them have been thoroughly validated, so feel free to pick any method you wish and tell us why you picked it…
Why did you choose to oversubscribe the cores with 4 threads?
Answer: I wanted to use exactly the same settings across all platforms under test. The only platform in my ARM versus x86 report to benefit from forking was the Intel Atom; if all CPUs had been single-core without HyperThreading, I would have only used one thread. As you know, threading/forking places greater pressure on caches and memory and I wanted to keep this consistent across all systems under test.
* We like this approach, though what is a fair comparison? As mentioned in previous posts, CoreMark is not really focused on multiple cores. We highly recommend using EEMBC MultiBench when trying to evaluate performance in a MultiCore environment.
Why did you under-clock the N450 to 1GHz when it normally runs at 1.66GHz? Did it change the core/bus ratio?
Answer: The ARM Cortex-A8 system ran at 800MHz and I wanted to have all of the platforms operate at this speed for a fair IPC performance comparison.
Unfortunately, the Atom N450 can only be downclocked to 1GHz, so that’s what I was forced to use. Only the multiplier was changed on the Atom and the VIA Nano L3050; adjusting the bus clock / system clock should always be avoided in performance benchmarking for many, many obvious reasons.
* For processors with even a small cache, CoreMark will operate entirely inside the cache, and will not be affected by memory performance at all. This is a critical concern for small embedded devices though, as mentioned in a previous blog post.
All in all, nice to see that industry analysts are picking up CoreMark and using it to test processors at any level. Check the news section to see the latest…