7 ms·

The “Uncanny Valley” of L3 Cache Contention

86 points by r4um 12y ago

rwmj 12y ago
Can anyone explain why the relative performance of different # threads spreads out again for working sets > 8 MB?
- deleted 12y ago
  [deleted]
  - TheLoneWolfling 12y ago
    L2 cache isn't shared, at least looking at the die picture.
    - nly 12y ago
      You're right. I forgot what was being measured here.
    - djcapelis 12y ago
      I'm not sure if it's happening here, but for what it's worth, it's not true that L2 can't be shared. On cores with hyperthreading, it's a shared resource. You can see the impact of this contention on some data generated on an i5-650 here: http://tmp.capelis.dj/2014/l2c.png http://tmp.capelis.dj/2014/l2c.png
      - TheLoneWolfling 12y ago
        Huh. Now that I look at it, you can actually see the effects of it on the graph in the article. Look at scalability at 128k and 256k.
        djcapelis 12y ago
        Yes, also notice how those dips show up more for even numbers of threads than odd numbers of threads. :) That system is hyperthreading.
- Tuna-Fish 12y ago
  At that point, the performance of his benchmark depends of DRAM access. In modern system, DRAM is very parallel -- a single access is glacially slow but you can have a lot of accesses in flight. It would appear that a single thread of his benchmark cannot provide enough access parallelism to saturate his DRAM interfaces.
- TillE 12y ago
  More threads can probably queue up memory requests a bit faster than one thread which is doing some processing between requests. I can't explain the precise convergence at the 8MiB mark, though.
- deleted 12y ago
  [deleted]
- djcapelis 12y ago
  When the threads are hitting memory anyway, the cache is less hot, so the contention on the cache is actually reduced.
pron 12y ago
The code for the benchmark: https://github.com/mikeb01/qconsf2014/blob/master/src/main/java/com/lmax/qconsf2014/l3/L3CacheBenchmark.java https://github.com/mikeb01/qconsf2014/blob/master/src/main/j...
jeffreyrogers 12y ago
This is great. I've come across a few articles lately about caches and their effects on performance. It's really interesting stuff. If this interested you, then you might find this article[1] by Dan Luu on improving performance by misaligning data interesting as well. [1]: http://danluu.com/3c-conflict/ http://danluu.com/3c-conflict/

86 points by r4um 12y ago

rwmj 12y ago

Can anyone explain why the relative performance of different # threads spreads out again for working sets > 8 MB?

deleted 12y ago
[deleted]
- TheLoneWolfling 12y ago
  L2 cache isn't shared, at least looking at the die picture.
  - nly 12y ago
    You're right. I forgot what was being measured here.
  - djcapelis 12y ago
    I'm not sure if it's happening here, but for what it's worth, it's not true that L2 can't be shared. On cores with hyperthreading, it's a shared resource. You can see the impact of this contention on some data generated on an i5-650 here: http://tmp.capelis.dj/2014/l2c.png http://tmp.capelis.dj/2014/l2c.png
    - TheLoneWolfling 12y ago
      Huh. Now that I look at it, you can actually see the effects of it on the graph in the article. Look at scalability at 128k and 256k.
      - djcapelis 12y ago
        Yes, also notice how those dips show up more for even numbers of threads than odd numbers of threads. :) That system is hyperthreading.
Tuna-Fish 12y ago
At that point, the performance of his benchmark depends of DRAM access. In modern system, DRAM is very parallel -- a single access is glacially slow but you can have a lot of accesses in flight. It would appear that a single thread of his benchmark cannot provide enough access parallelism to saturate his DRAM interfaces.
TillE 12y ago
More threads can probably queue up memory requests a bit faster than one thread which is doing some processing between requests. I can't explain the precise convergence at the 8MiB mark, though.
deleted 12y ago
[deleted]
djcapelis 12y ago
When the threads are hitting memory anyway, the cache is less hot, so the contention on the cache is actually reduced.

pron 12y ago

The code for the benchmark: https://github.com/mikeb01/qconsf2014/blob/master/src/main/java/com/lmax/qconsf2014/l3/L3CacheBenchmark.java https://github.com/mikeb01/qconsf2014/blob/master/src/main/j...

jeffreyrogers 12y ago

This is great. I've come across a few articles lately about caches and their effects on performance. It's really interesting stuff. If this interested you, then you might find this article[1] by Dan Luu on improving performance by misaligning data interesting as well. [1]: http://danluu.com/3c-conflict/ http://danluu.com/3c-conflict/