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.

When we first reviewed the 10-core Comet Lake processors, we noticed that a core (or two) seemed to take slightly longer to ping/pong than the others. These two parts are both derived from the 10-core silicon but with two cores disabled, and we still see a pattern of some cores having additional latency. The ring on the 8-core parts still acts like a 10-core ring, but it all depends on which cores were disabled.

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.

Both processors ramp from idle to full turbo in about six milliseconds, well within a single frame of standard gaming.

Power Consumption CPU Tests: Office and Science
Comments Locked

210 Comments

View All Comments

  • dullard - Thursday, January 21, 2021 - link

    Yes, it is sad that even well respected PhDs in the field can't seem to understand that TDP is not total consumed power. Never has been, never will be. TDP is simply the minimum power to design your cooling system around.

    I actually think that Intel went in the right direction with Tiger Lake. It will do everyone a service to drop any mention of TDP solely into the fine print of tech documents because so many people misunderstand it.

    Yes, TSMC has a fantastic node right now with lower power that AMD is making good use of. Yes, that makes Intel look bad. Lets clearly state that fact and move on.

    Power usage matters for mobile (battery life), servers (cooling requirements and energy costs), and the mining fad (profits). Power usage does not matter to most desktop users.
  • dullard - Thursday, January 21, 2021 - link

    Also don't forget that we are talking about 12 seconds or 28 seconds of more power, then it drops back down unless the motherboard manufacturer overrides it. The costs to desktop users for those few seconds is fractions of a penny.
  • bji - Thursday, January 21, 2021 - link

    "minimum power to design your cooling system around" makes NO SENSE.

    You don't design any cooling system to handle the "minimum", you design it to handle the "maximum".

    It sounds like you've bought into Intel's convoluted logic for justifying their meaningless TDP ratings?
  • iphonebestgamephone - Thursday, January 21, 2021 - link

    Why are there low end and high end coolers then? Arent the cheap ones for the minimum, in this case 65w?
  • Spunjji - Friday, January 22, 2021 - link

    dullard's comments are, indeed, a post-hoc justification in search of an audience.
  • dullard - Friday, January 22, 2021 - link

    Bji, no, that is not how how engineering works. You need to know the failure limit on the minimum side. If your cooling system cannot consistently cool at least 65W, then your product will fail to meet specifications. That is a very important number for a system designer. Make a 60W cooling system around the 10700 chip and you'll have a disaster.

    You can always cool more than 65W and have more and/or faster turbos. There is no upper limit to how much cooling capability you can use. A 65W cooler will work, a 125W cooler will work, a 5000 W cooler will work. All you get with better cooling is more turbo, more often. That is a selling point, but that is it - a selling point. It is the the 65W number that is the critical design requirement to avoid failures.
  • edzieba - Friday, January 22, 2021 - link

    Minor correction on " Never has been, never will be": TDP and peak package power draw WERE synonymous once, for consumer CPUs, back when a CPU just ran at a single fixed frequency all the time. It's not been true for a very long time, but now persists as a 'widely believed fact'.
    Something being true only in very specific scenarios but being applied generally out of ignorance is pretty common in the 'enthusiast' world: RAM heatsinks (if you're not running DDR2 FBDIMMs they're purely decorative), m.2 heatsinks (cooling the NAND dies is actively harmful, cooling the controller was only necessary for a single model of OEM-only brown-box Samsung drives because nobody had the tool to tell the controller to not run at max power all the time), hugely oversized WC radiators (from the days when rad area was calculated assuming repurposed low-density-high-flow car AC radiators, not current high-density-low-flow radiators), etc.
    Even now "more cores = more better" in the consumer market, despite very few consumer-facing workloads spanning more than a handful of threads (and rarely maxing out more than a single core).
  • dullard - Friday, January 22, 2021 - link

    I'll give you credit there. I should have said "not since turbo" instead of "never has been". Good catch. I wish there was an edit button.
  • Spunjji - Friday, January 22, 2021 - link

    What's really sad is that you apparently prefer to write a long comment trying to dunk on the author, rather than read the article he wrote for you to enjoy *for free*.

    "I actually think that Intel went in the right direction with Tiger Lake"
    You think poorly.

    "Yes, TSMC has a fantastic node right now with lower power that AMD is making good use of. Yes, that makes Intel look bad. Lets clearly state that fact and move on."
    Aaaand there's the motivation for the sour grapes.
  • dullard - Friday, January 22, 2021 - link

    Spunjji, I must assume since you didn't have anything to actually refute what I said, that you have nothing to refute it and instead choose to bash the messenger. Thanks for backing me up!

Log in

Don't have an account? Sign up now