By: Linus Torvalds (torvalds.delete@this.linux-foundation.org),
Room: Moderated Discussions
John Poole (john.delete@this.primatelabs.com) on September 26, 2013 2:59 pm wrote:
>
> Outside of enterprise software stacks we're not aware of scenarios where L1I cache misses
> have a significant impact on performance. Are there scenarios that we've missed?
There are absolutely tons of loads that don't come even close to fitting in L1I. People already mentioned browsers, and the point would be to load a new page, not load some single page that then has some specific single element on it that is heavy.
In fact, my experience is totally opposite from yours. Stuff that has a small code footprint I'm not at all interested in hearing benchmarks for, because I already know it will be "fast enough". If it's some common graphics thing, it's accelerated by the GPU. If it's not graphics-related, I can't even imagine why I'd ever want to run some kernel like that on my phone.
Do you really claim otherwise? Do you really find that it's the _simple_ things that are too slow, so you want to benchmark those kinds of loads? That makes no sense.
The crypto benchmarks make no sense either. Nobody does pure crypto. On a phone or tablet, your crypto is going to be dwarfed by the IO speed - either network or the flash write speed. Why would anybody encrypt/decrypt something that isn't sent out/received externally? So why bother testing something irrelevant? Are you expecting cracker networks to use their cellphones to crack passwords?
A small code footprint also almost totally hides things like branch prediction table sizes etc. And branch mis-prediction in turn doesn't just affect the pipeline, it affects how well you can prefetch both code and data through OoO. So it's not just I$ fetch, it's a lot of things that go along with "small trivial code size".
Making the data working set larger doesn't change any of these kinds of issues. It just makes the repeat-rates higher, and puts pressure on the D$. Yes, that in turn shows if the memory pipe is complete crap, but it really misses a lot about the core CPU.
Complex GUI stuff (and phones/tablets are definitely moving in that direction) tends to have all these fancy GUI libraries, often object-oriented ones. And you see code with tons of indirect function calls, lots of wrapper functions (ie one function massages some arguments a bit and then just calls another function), and no, it's not inlined because it's often all about interfacing between different library levels (webkit, various font rendering libraries, low-level drivers for "in memory" vs "on screen" yadda yadda).
That's how "hot loops" end up being bigger than the L1 I$. Rendering an anti-aliased glyph really is a lot more complicated than doing a SHA-1 round. And that's just one glyph. Now do layout for a full web-page etc.
Linus
>
> Outside of enterprise software stacks we're not aware of scenarios where L1I cache misses
> have a significant impact on performance. Are there scenarios that we've missed?
There are absolutely tons of loads that don't come even close to fitting in L1I. People already mentioned browsers, and the point would be to load a new page, not load some single page that then has some specific single element on it that is heavy.
In fact, my experience is totally opposite from yours. Stuff that has a small code footprint I'm not at all interested in hearing benchmarks for, because I already know it will be "fast enough". If it's some common graphics thing, it's accelerated by the GPU. If it's not graphics-related, I can't even imagine why I'd ever want to run some kernel like that on my phone.
Do you really claim otherwise? Do you really find that it's the _simple_ things that are too slow, so you want to benchmark those kinds of loads? That makes no sense.
The crypto benchmarks make no sense either. Nobody does pure crypto. On a phone or tablet, your crypto is going to be dwarfed by the IO speed - either network or the flash write speed. Why would anybody encrypt/decrypt something that isn't sent out/received externally? So why bother testing something irrelevant? Are you expecting cracker networks to use their cellphones to crack passwords?
A small code footprint also almost totally hides things like branch prediction table sizes etc. And branch mis-prediction in turn doesn't just affect the pipeline, it affects how well you can prefetch both code and data through OoO. So it's not just I$ fetch, it's a lot of things that go along with "small trivial code size".
Making the data working set larger doesn't change any of these kinds of issues. It just makes the repeat-rates higher, and puts pressure on the D$. Yes, that in turn shows if the memory pipe is complete crap, but it really misses a lot about the core CPU.
Complex GUI stuff (and phones/tablets are definitely moving in that direction) tends to have all these fancy GUI libraries, often object-oriented ones. And you see code with tons of indirect function calls, lots of wrapper functions (ie one function massages some arguments a bit and then just calls another function), and no, it's not inlined because it's often all about interfacing between different library levels (webkit, various font rendering libraries, low-level drivers for "in memory" vs "on screen" yadda yadda).
That's how "hot loops" end up being bigger than the L1 I$. Rendering an anti-aliased glyph really is a lot more complicated than doing a SHA-1 round. And that's just one glyph. Now do layout for a full web-page etc.
Linus
