CPU Tests: Microbenchmarks

Core-to-Core Latency

As the core count of modern CPUs is growing, we are reaching a time when the time to access each core from a different core is no longer a constant. Even before the advent of heterogeneous SoC designs, processors built on large rings or meshes can have different latencies to access the nearest core compared to the furthest core. This rings true especially in multi-socket server environments.

But modern CPUs, even desktop and consumer CPUs, can have variable access latency to get to another core. For example, in the first generation Threadripper CPUs, we had four chips on the package, each with 8 threads, and each with a different core-to-core latency depending on if it was on-die or off-die. This gets more complex with products like Lakefield, which has two different communication buses depending on which core is talking to which.

If you are a regular reader of AnandTech’s CPU reviews, you will recognize our Core-to-Core latency test. It’s a great way to show exactly how groups of cores are laid out on the silicon. This is a custom in-house test built by Andrei, and we know there are competing tests out there, but we feel ours is the most accurate to how quick an access between two cores can happen.

The core-to-core numbers are interesting, being worse (higher) than the previous generation across the board. Here we are seeing, mostly, 28-30 nanoseconds, compared to 18-24 nanoseconds with the 10700K. This is part of the L3 latency regression, as shown in our next tests.

One pair of threads here are very fast to access all cores, some 5 ns faster than any others, which again makes the layout more puzzling. 

Update 1: With microcode 0x34, we saw no update to the core-to-core latencies.

Cache-to-DRAM Latency

This is another in-house test built by Andrei, which showcases the access latency at all the points in the cache hierarchy for a single core. We start at 2 KiB, and probe the latency all the way through to 256 MB, which for most CPUs sits inside the DRAM (before you start saying 64-core TR has 256 MB of L3, it’s only 16 MB per core, so at 20 MB you are in DRAM).

Part of this test helps us understand the range of latencies for accessing a given level of cache, but also the transition between the cache levels gives insight into how different parts of the cache microarchitecture work, such as TLBs. As CPU microarchitects look at interesting and novel ways to design caches upon caches inside caches, this basic test proves to be very valuable.

Looking at the rough graph of the 11700K and the general boundaries of the cache hierarchies, we again see the changes of the microarchitecture that had first debuted in Intel’s Sunny Cove cores, such as the move from an L1D cache from 32KB to 48KB, as well as the doubling of the L2 cache from 256KB to 512KB.

The L3 cache on these parts look to be unchanged from a capacity perspective, featuring the same 16MB which is shared amongst the 8 cores of the chip.

On the DRAM side of things, we’re not seeing much change, albeit there is a small 2.1ns generational regression at the full random 128MB measurement point. We’re using identical RAM sticks at the same timings between the measurements here.

It’s to be noted that these slight regressions are also found across the cache hierarchies, with the new CPU, although it’s clocked slightly higher here, shows worse absolute latency than its predecessor, it’s also to be noted that AMD’s newest Zen3 based designs showcase also lower latency across the board.

With the new graph of the Core i7-11700K with microcode 0x34, the same cache structures are observed, however we are seeing better performance with L3.

The L1 cache structure is the same, and the L2 is of a similar latency. In our previous test, the L3 latency was 50.9 cycles, but with the new microcode is now at 45.1 cycles, and is now more in line with the L3 cache on Comet Lake.

Out at DRAM, our 128 MB point reduced from 82.4 nanoseconds to 72.8 nanoseconds, which is a 12% reduction, but not the +40% reduction that other media outlets are reporting as we feel our tools are more accurate. Similarly, for DRAM bandwidth, we are seeing a +12% memory bandwidth increase between 0x2C and 0x34, not the +50% bandwidth others are claiming. (BIOS 0x1B however, was significantly lower than this, resulting in a +50% bandwidth increase from 0x1B to 0x34.)

In the previous edition of our article, we questioned the previous L3 cycle being a larger than estimated regression. With the updated microcode, the smaller difference is still a regression, but more in line with our expectations. We are waiting to hear back from Intel what differences in the microcode encouraged this change.

Frequency Ramping

Both AMD and Intel over the past few years have introduced features to their processors that speed up the time from when a CPU moves from idle into a high powered state. The effect of this means that users can get peak performance quicker, but the biggest knock-on effect for this is with battery life in mobile devices, especially if a system can turbo up quick and turbo down quick, ensuring that it stays in the lowest and most efficient power state for as long as possible.

Intel’s technology is called SpeedShift, although SpeedShift was not enabled until Skylake.

One of the issues though with this technology is that sometimes the adjustments in frequency can be so fast, software cannot detect them. If the frequency is changing on the order of microseconds, but your software is only probing frequency in milliseconds (or seconds), then quick changes will be missed. Not only that, as an observer probing the frequency, you could be affecting the actual turbo performance. When the CPU is changing frequency, it essentially has to pause all compute while it aligns the frequency rate of the whole core.

We wrote an extensive review analysis piece on this, called ‘Reaching for Turbo: Aligning Perception with AMD’s Frequency Metrics’, due to an issue where users were not observing the peak turbo speeds for AMD’s processors.

We got around the issue by making the frequency probing the workload causing the turbo. The software is able to detect frequency adjustments on a microsecond scale, so we can see how well a system can get to those boost frequencies. Our Frequency Ramp tool has already been in use in a number of reviews.

Our ramp test shows a jump straight from 800 MHz up to 4900 MHz in around 17 milliseconds, or a frame at 60 Hz. 

Power Consumption: Hot Hot HOT CPU Tests: Office and Science
POST A COMMENT

540 Comments

View All Comments

  • Zoeff - Friday, March 5, 2021 - link

    Now this is a welcome surprise! Reply
  • nandnandnand - Friday, March 5, 2021 - link

    This is actually Intel's best product launch ever. Because you can buy it and get in on the class action lawsuit later. Reply
  • Zoeff - Friday, March 5, 2021 - link

    To be clear, I was referring to the article itself.

    But yes the performance is also a surprise for me after going through the article. I expected a nice performance uplift, perhaps a bit faster than Ryzen 5000 but with a higher power draw as a trade off for being on the same Intel 14nm node still. Definitely did NOT expect it to be slower.
    Reply
  • nandnandnand - Friday, March 5, 2021 - link

    To be clear, I was replying to you to get a reply at the top of the comments. Completely self-serving manipulation of AnandTech's comment section.

    Hopefully, terroradagio is right and an update will improve performance and efficiency slightly. Also, I wonder how the 11900K will look going ~200-300 MHz above this.
    Reply
  • barich - Friday, March 5, 2021 - link

    I have a feeling that the additional power draw required to get that extra 2-300 MHz is going to be well out of proportion to the performance gained by it. This chip is already pushed past the edge just to not regress (usually) over the previous generation. Reply
  • whatthe123 - Friday, March 5, 2021 - link

    Considering this chip is already drawing way too much power the 11900's are probably binned like crazy and run a much lower voltage. Even then it'll probably still use more power than the 11700k. I think they should've just accepted that 14nm was not going to work for this backport. There's a market for cometlake in gamers but what market is there for this? Niche scientific computing? Reply
  • terroradagio - Friday, March 5, 2021 - link

    Games don't require the type of power people here are crying about. Honestly, do people just sit at their computers and run AVX benchmarks all day? Reply
  • barich - Friday, March 5, 2021 - link

    You're still looking at like an 80W difference and a requirement for the best air cooling available if you don't want temps to be out of control. I might be willing to tolerate the extra power draw if I got more performance out of it, but that's not the case. Reply
  • eva02langley - Saturday, March 6, 2021 - link

    You mean LIQUID COOLING at this point. You need a good AIO with such power requirements. Reply
  • JimmyTheFish - Friday, March 5, 2021 - link

    No, power consumption is exactly as bad as people are "crying" about, this chips is a joke, hotter, slower and more expensive than even the quite Sub-Par cometlake chips on the market, nevermind the superb Zen 3 offerings, which are starting to see increased availability with the single CCD 6 and 8 core 5600X and 5800X

    To even be remotely appealing the 10700K need to be cheap, sub $350 cheap, and thats just not gonna happen
    Reply

Log in

Don't have an account? Sign up now