[Embench] Warm-up phase

Jeremy Bennett jeremy.bennett at embecosm.com
Sun May 9 12:41:41 CEST 2021

On 02/05/2021 11:37, Avishai Tvila wrote:
> I’m wondering why we need the warm-up phase at all.
> It seems the impact of cold caches/predictors is insignificant.

Hi Avishai,

Thanks for your contract.

> The impact of warm-up is highest when the whole data is fit in the
> cache, and the misses are only due to a cold cache.

Well there is also the impact on branch prediction as well. Plus some
small chips have low power modes with voltage and frequency scaling and
you want to make sure they are brought out of these fully.

> Therefore, the upper bound of warm-up gain per access is
> ((Miss-penalty)*(static data size)/(Dynamic accesses))*(base CPI)
> Warm-up has three parts:
>  1. I$ - for Embench, the code size is up to 16KB, the number of dynamic
>     instructions depends on clock frequency, but even for 10MHz, it’s
>     bigger than 80M instructions. Even if a missed penalty is 100s
>     cycles, the impact is about 0.
>  2. Branch Predictor – same as (1)
>  3. D$ - data size is limited to 64K, assuming cache line is 32B,
>     warming can save 2K misses. Assuming we have ~20% memory accesses,
>     it’s 2K out of 16M; even with a missed penalty of 300 cycles, it’s
>     only 0.03 cycles per memory access.

The impact varies greatly from chip to chip. We have this feature in
order to eliminate the issue for those chips where it does matter.

It is an interesting subject, and where it would be good to have
benchmarks to assess the impact of warm-up. But we have kept the scope
of the first Embench benchmarks deliberately simple in the interest of
being able to deliver something useful.

Embench 2.0 proposes a different way of measuring performance, comparing
complete runs with different scaling factors. This will effectively
eliminate any warm-up effect.

Best wishes,


> Thoughts?
> Best,
> Ofer & Avishai

Cell: +44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email: jeremy.bennett at embecosm.com
Web: www.embecosm.com
PGP key: 1024D/BEF58172FB4754E1 2009-03-20

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.librecores.org/pipermail/embench/attachments/20210509/2b0b645d/attachment.sig>

More information about the Embench mailing list