1
\$\begingroup\$

I have an application where I suspect the main overhead is accessing L3 cache. It is run on a modern Intel server-grade microprocessor with a huge L3 cache. There are many microprocessors available with various core counts and frequencies, and selecting between these is hard.

So, that led me to wonder whether L3 cache access (hit) time scales down with frequency. So, if 2GHz CPU accesses L3 cache in e.g. 12 ns, does that mean that a 3GHz CPU accesses L3 cache in 8 ns? Of course, this may depend on internal implementation details of the CPU, so let's limit answers to modern i386/AMD64 microprocessors.

I know that at least in the case of DRAM the delays are practically constant, so if you do a random DRAM access, higher frequency means only better sequential data rate after the random access penalty has been paid. But is SRAM fundamentally different? It is based on transistors, so I guess it could be clocked at pretty good frequencies.

Sorry if this is the wrong place to ask, there is no better place to ask detailed computer architecture questions. I have considered CS StackExchange and StackOverflow, but I think Electrical Engineering StackExchange was the best place. There really should be a Computer Architecture StackExchange but there isn't!

\$\endgroup\$
2
  • \$\begingroup\$ one would hope it would scale linearly but I wouldnt assume so. by 2GHz for example you may have maxed out that L3 bus and any faster the core goes the L3 cant increase. As an example. Multiply this by every bus on every layer between the internals of the core and the slowest furthest away dram. And that is just for starters, then there are the gory details... \$\endgroup\$
    – old_timer
    Commented Jul 27, 2017 at 20:51
  • \$\begingroup\$ sram can be run faster than dram sure and at times can scale with the cpu (register files in the cpu for example, possibly L1 cache). But for various reasons, particularly physics, it is not going to be linear from inside out to the dram. \$\endgroup\$
    – old_timer
    Commented Jul 27, 2017 at 20:54

2 Answers 2

2
\$\begingroup\$

It was in old days (mid-90') when every CPU block did scale with frequency. With modern processors it is not true anymore. The CPU core and caches have different design topologies, and memories usually do not scale much. The timing alignment between CPU core clock and caches is usually done by re-configuring the pipeline access to cache, so it is very likely that the cacheline access time doesn't scale with core frequency at all. I recall running into similar issues while working on K6 processors, when for every clock multiplier the cache access must be re-configured.

With modern CPUs and adaptive core frequency the things are much-much more complicated. CPUs are designed by thousands of design engineers and architected by hundreds of architects, so to get into details you need top clearance access to top secret documentation, and even then it will be difficult to find the exact answer.

\$\endgroup\$
0
\$\begingroup\$

There's 3 main different clock domains. Memory, uncore (L3), and core. All of these swing at different frequencies and all are controlled individually by complex algorithms. At a broad level, your core clocks can scale from sub-GHz to 2 to 5 GHz depending on your cpu. Uncore swings from the same low end to about half of the core frequency. If you're not accessing much from L3/IIO/Memory, the algorithms will probably keep the uncore clock low and prevent you from seeing the absolute fastest L3 access times unless you have a specific set of stressors. There may be customer visible knobs to adjust these items as well, but I'm not sure.

More than anything, I would suspect smaller core count cpus to be able to reach higher uncore clock speeds (thereby decreasing your L3 cache access time). To be clear though, core clock frequencies have no direct correlation to the uncore clock so increasing your core clock frequency alone won't increase L3 cache speed.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.