Thanks. I could have thought it with the TCM memory.
This is quite normal. Coremark will probably run inside the core's cache and thus only use the core itself. You're test is probably using the memory and this is shared.
CoreMark Multi Core Reporting Requirement
According to the official EEMBC CoreMark Run and Reporting Rules
(`docs/run_and_report.pdf`, Section 1.2), each CoreMark instance must run
on exactly one CPU core, and all instances must be reported separately:
“Each CoreMark instance must execute on a single core. When running
multiple instances, each instance must be reported separately.”
This project follows the EEMBC requirement by pinning each CoreMark
process to a dedicated core and reporting per core results individually.🧵 What the CoreMark Multi Thread Setting Actually Does
CoreMark does not implement real multithreading in the sense of shared memory parallelism, mutexes, or work stealing. Instead, the “multi thread” setting simply creates multiple independent CoreMark contexts, each of which:
• Runs the full CoreMark workload
• Has its own data structures
• Does not share memory with other contexts
• Must run on one CPU core only (per EEMBC rules)
Think of it as launching N separate CoreMark instances inside one process.
🧩 What It Does Internally
When you enable multi thread mode:
• CoreMark allocates N copies of the benchmark state
• It spawns N threads, each running one context
• Each thread executes the benchmark loop independently
• There is no synchronization between threads
• There is no parallel speedup unless the OS schedules each thread on a different core
This is why EEMBC calls them contexts, not threads.
🧠 What It Does Not Do
The multi thread setting does not:
• Split the workload across cores
• Parallelize the benchmark
• Measure shared memory performance
• Measure thread scalability
• Measure OS thread scheduling performance
• Combine results into a single “multi core score”
CoreMark is intentionally not a system benchmark.
📊 How Results Must Be Reported
EEMBC requires:
• Each thread/context = one CoreMark instance
• Each instance must be reported separately
• You may optionally show a “total throughput” number, but only after listing each instance individually
This is why vendors report results like:
Core 0: 3.21 CoreMark/MHz
Core 1: 3.20 CoreMark/MHz
Core 2: 3.21 CoreMark/MHz
Core 3: 3.20 CoreMark/MHz
Total: 12.82 CoreMark/MHz
🛠️ Practical Meaning for You
If you set MULTITHREAD=4, CoreMark will:
• Spawn 4 threads
• Run 4 independent benchmarks
• Rely on the OS to schedule them
• Produce 4 separate scores
If you want true per core correctness, you must:
• Pin each thread to a specific core
• Or run 4 separate processes, each pinned to a coreThat looks pretty good and doable. Are there any volunteers?How Results Must Be Reported
EEMBC requires:
• Each thread/context = one CoreMark instance
• Each instance must be reported separately
• You may optionally show a “total throughput” number, but only after listing each instance individually
This is why vendors report results like:
Core 0: 3.21 CoreMark/MHz
Core 1: 3.20 CoreMark/MHz
Core 2: 3.21 CoreMark/MHz
Core 3: 3.20 CoreMark/MHz
Total: 12.82 CoreMark/MHz
Practical Meaning for You
If you set MULTITHREAD=4, CoreMark will:
• Spawn 4 threads
• Run 4 independent benchmarks
• Rely on the OS to schedule them
• Produce 4 separate scores
If you want true per core correctness, you must:
• Pin each thread to a specific core
• Or run 4 separate processes, each pinned to a core
[/CODE]
So question for everyone is does this make sense and when dealing with multi-core processors really have to show results for both?
That looks pretty good and doable. Are there any volunteers?
I had a play with this one (link to dev branch with a “better” implementation of
yield()). It worked fine, but I didn’t explore deeply enough to find out whether the thread-naïve Teensy libraries cause serious issues.Maybe I should install the pico 2 toolchain.Right now only have a Teensy that I can run it on - don't have an RP dual core. But its on my to do list which seems to be getting longer and longer.