AMD Ryzen 7 2700X Review: Redefining Ryzen

[PaulAlcorn]

Only ONE tech review website deemed it worthy of a re-do based on inconsistencies of other site reviews, and yep, that's Anandtech.

Tom's Hardware admitted right in their review to having a problem with their testing methodology, namely that they made the mistake of not realizing that their X470 motherboard was already patched for Spectre, so they didn't apply patched firmware to their Intel motherboard, potentially providing Intel's CPUs with an unfair advantage in their test results. Whether that made any notable difference to how those processors performed is yet to be seen, but it's certainly possible. Unfortunately, they tucked that information away on the test setup page instead of posting it somewhere more prominent, so many readers probably missed it...

Unfortunately, we were only made aware that Variant 2 mitigations are present in our X470 board's firmware just before launch, precluding us from re-testing the Intel platforms with patches applied. We're working on this now, and plan to post updated results in future reviews.

The lack of Spectre Variant 2 patches in our Intel results likely give the Core CPUs a slight advantage over AMD's patched platforms. But the performance difference should be minimal with modern processors.

Anandtech has published an article detailing their findings and it's really quite interesting. Hopefully the folks at Tom's and other review sites are familiar with, or become aware of why Anandtech's benchmark numbers went the way they did.

Anandtech update

The gist of the matter is, Spectre and Meltdown mitigations decrease the performance of IO operations on Intel platforms. The HPET (High Precision Event Timer) is mapped in such a way, accessing it constitutes an IO operation. Forcing Windows to use HPET as it's primary timer has a major impact on Intel's CPU performance in cases where the software makes use of the timer. The difference hasn't been quantified between pre- and post-patched machines yet, but it's not an unfair assessment to say there won't be a performance difference, and the final result won't change anyway. HPET being used as the primary timer in Windows with a patched Intel system seems to come with a very high performance penalty.

It would be a nice addition to any benchmark setup pages going forward to include the state of the HPET timer settings, both in UEFI and the Windows setting used. Anandtech also points out that installing software can change the HPET setting in Windows, so the step at which the Windows HPET setting is looked at and potentially modified by the reviewer should obviously be after all pertinent software has been installed.

No conspiracies or intentional biases seem to have been necessary for the interesting results found by the Anandtech reviewers.

An honest mistake. Ian works hard, so this is surely a bit disappointing for him.

We test with the default OS behavior, which is HPET disabled. We also enforce this with a hard disable in our test scripts.

As an aside, there are several tools that you can use to check the resolution of the windows timer. It is important to make sure that this in-built timer is consistent across test platforms, as well. I check the resolution on every new test platform as SOP to ensure consistent and accurate benchmark results across platforms.

Interestingly, the primary reason that HPET still exists is to ensure backwards compatibility with older programs that rely on it, the same old kludge as always.

 

[bigpinkdragon286]

An honest mistake. Ian works hard, so this is surely a bit disappointing for him.

We test with the default OS behavior, which is HPET disabled.

Didn't realize you were still following the musings of the peasantry down below, but it's nice to see. Thanks for your reply and also for clarifying your HPET setting. I think most of you guys work hard, especially knowing how many of us nit pickers are going to scrutinize every last detail you put out.

Whether it was a mistake or not, I am actually pleased that as a result, the effect HPET can have on different platforms is highlighted so well for a vast number of people. It's a good learning experience that may not have happened had Ian not made the choice he did for his testing. Thankfully it sounds like he's got most things automated, so it's just a matter of time for the machines to perform retesting, and he doesn't have to go nuts doing it all manually.

Based on the explanation in your sister site's article, I actually don't expect to see a significant decrease in performance on the Intel platform in any of your updated numbers with the latest Spectre and Meltdown mitigations applied. It looks like the largest performance loss was due to using the IO bound HPET.

I generally feel that most of the reviewers out there go in with reasonably honest intentions, and those intentions aren't always the same thing, and I suspect there's no bias or conspiracy involved in that decision making process even if the reviewer has their own personal preferences.

The biggest issue I see is a bunch of keyboard warriors expecting something on the order of scientific comparability between the various reviews being done and that's just not realistic.

I highly doubt that all of the review sites could ever agree on which motherboard, firmware, Windows version, patching level, testing suite and methodology, and finally which knobs and dials to turn in UEFI, to make for more directly comparable results. Even if a consensus was reached, you could hardly expect high levels of participation, as many review sites seem reliant on the motherboard and memory kit samples they are sent, by varying manufacturers.

I would certainly find it interesting if two or more sites did collaborate on an article, to test the viability of scientifically repeatable benchmarking.

As it is, perhaps some consumers of reviews need a lesson in interpreting results, and a further lesson in interpreting the reviewers' interpretation of those results.

 

[PaulAlcorn]

An honest mistake. Ian works hard, so this is surely a bit disappointing for him.

We test with the default OS behavior, which is HPET disabled.

Didn't realize you were still following the musings of the peasantry down below, but it's nice to see. Thanks for your reply and also for clarifying your HPET setting. I think most of you guys work hard, especially knowing how many of us nit pickers are going to scrutinize every last detail you put out.

Whether it was a mistake or not, I am actually pleased that as a result, the effect HPET can have on different platforms is highlighted so well for a vast number of people. It's a good learning experience that may not have happened had Ian not made the choice he did for his testing. Thankfully it sounds like he's got most things automated, so it's just a matter of time for the machines to perform retesting, and he doesn't have to go nuts doing it all manually.

Based on the explanation in your sister site's article, I actually don't expect to see a significant decrease in performance on the Intel platform in any of your updated numbers with the latest Spectre and Meltdown mitigations applied. It looks like the largest performance loss was due to using the IO bound HPET.

I generally feel that most of the reviewers out there go in with reasonably honest intentions, and those intentions aren't always the same thing, and I suspect there's no bias or conspiracy involved in that decision making process even if the reviewer has their own personal preferences.

The biggest issue I see is a bunch of keyboard warriors expecting something on the order of scientific comparability between the various reviews being done and that's just not realistic.

I highly doubt that all of the review sites could ever agree on which motherboard, firmware, Windows version, patching level, testing suite and methodology, and finally which knobs and dials to turn in UEFI, to make for more directly comparable results. Even if a consensus was reached, you could hardly expect high levels of participation, as many review sites seem reliant on the motherboard and memory kit samples they are sent, by varying manufacturers.

I would certainly find it interesting if two or more sites did collaborate on an article, to test the viability of scientifically repeatable benchmarking.

As it is, perhaps some consumers of reviews need a lesson in interpreting results, and a further lesson in interpreting the reviewers' interpretation of those results.

We'll have the updated results with the fourth and final patch in our 2600X article, which I'm actually typing up now. We're also throwing in the pre- and post-patch test results, which are interesting, but definitely not far from the expected performance regressions.

Diversity in testing methods and applications is actually a good thing--it broadens the scope for enthusiasts. You can always go read a few articles and find a few different viewpoints and tests. Of course, methodology is always different, so you are right: You should never compare test results directly between sites. It is instructive for general trends, though.

 

[bigpinkdragon286]

We'll have the updated results with the fourth and final patch in our 2600X article, which I'm actually typing up now. We're also throwing in the pre- and post-patch test results, which are interesting, but definitely not far from the expected performance regressions.

Looking forward to it! I think more for the Intel numbers and your findings in regards the patches, since I don't really expect too many surprises out of the 2600X CPU. Will be nice to be able to move past the speculation around performance losses.

Diversity in testing methods and applications is actually a good thing--it broadens the scope for enthusiasts. You can always go read a few articles and find a few different viewpoints and tests. Of course, methodology is always different, so you are right: You should never compare test results directly between sites. It is instructive for general trends, though.

Completely agree with you.

As an aside, there are several tools that you can use to check the resolution of the windows timer. It is important to make sure that this in-built timer is consistent across test platforms, as well. I check the resolution on every new test platform as SOP to ensure consistent and accurate benchmark results across platforms.

Interestingly, the primary reason that HPET still exists is to ensure backwards compatibility with older programs that rely on it, the same old kludge as always.

I suspect I've already looked at and used several of those timer tools. It's reassuring to hear you are doing your due diligence, especially as most review articles don't usually go into that sort of detail.

The rest, I'm sure you already know, but other readers might not be overly familiar with the history of the HPET in PCs.

The HPET seems only to have been significantly useful for a few years, from the point multi-core CPUs shipped, until the CPU designers implemented invariant TSC.

My understanding of HPET was that it was used to provide a timer with a 1 microsecond or better resolution at the time of Windows Vista, when many CPUs in use were only able to provide non-invariant TSC for high resolution timing. TSC was just fine for this purpose before clock frequencies starting jumping around due to the introduction of technologies like SpeedStep and Cool'N'Quiet. This was remedied with Constant TSC, which worked until multi-core CPUs hit the consumer space, at which point TSC couldn't be synchronized across the cores.

As the HPET is usually based off the ACPI timer being provided by the platform, rather than CPU, it ends up being addressed through IO mapping. It makes perfect sense that this would impact gaming on Intel setups post patch, if the games are using a lot of timers or timing metrics and the patches impact IO performance.

By the time Windows 7 shipped, most systems should have defaulted back to TSC as CPUs by then started implementing the invariant TSC, and with Windows 8, Microsoft improved their TSC syncing algorithm further, as Microsoft states, "to better accommodate large systems with many processors."

The benefit of iTSC is the low setup and overhead involved for the high resolution results. HPET really only seems applicable in those cases where you're running a CPU providing only non-invariant TSC, and where you need high resolution timing. It comes with high latency and lots of overhead if it's being used often.

Apparently, in the original Ryzen CPUs, TSC is tied to the base clock, P0 state (no idea if that's changed at all with Ryzen+), and in Windows 8 & 10, the UI compositor is reliant on the system timer. When you use AMD's Ryzen Master software to overclock a Ryzen CPU on Windows 10, you need HPET to provide a clock source for the Windows UI compositor that is independent of the CPU's base clock, otherwise the compositor stops working. I guess HPET is good for that, but it's probably best to set the overclock manually in UEFI and turn HPET back off again, once the Ryzen Master software has determined numbers for overclocking.

 

[PaulAlcorn]

<snip>

Yup, we ran into the HPET issues with our first Ryzen review. From the conclusion:

Further, AMD suggests adjusting several different parameters for games that suffer from low performance. It recommends using Windows' High Performance power profile (which also helps Intel CPUs). It also says to disable the HPET (High Precision Event Timer), either in your BIOS or operating system, to gain a 5-8% advantage. Our results already reflect HPET disabled, though. Interestingly, AMD's Ryzen Master software requires HPET to “provide accurate measurements,” so you may find yourself toggling back and forth for the best experience.

AMD fixed the issues, and a few representatives commented on this earlier this week. https://www.reddit.com/r/Amd/comments/8ed47q/hpet_on_ryzen_2000_series/

As to HPET, Microsoft disabled it by default in its OS nearly a decade ago, and for a reason. It has long had a performance overhead, even before the patches. I've recorded significant deltas in games long ago, hence why I ensure that it is in the default disabled setting. The patches aggravate it, though.

 

[diacad]

SAKKURA 5 days ago

Anonymous (DIACAD) said:
I agree the Ryzen 2700 is a hot chip, but it may not be for everyone. Last year I tried to configure a server with the 2700 and found it seemed incompatible with VMware - at least without hamburger helpers I was unwilling to use. So I put the 2700 on the shelf and switched to a Xeon based board. I have also heard (but had no experience) that there are 2700 problems with Linux. Why aren't these issues openly discussed? Not everyone is a Windows gamer - where the 2700 is undoubtedly a prime contender.



SAKKURA: Uh... the 2700 was not available last year.

(Diacad to Sakkura You are most probably right - the chip I used was actually the 1700, purchased April 17, 2017. Sorry for the memory slip, but I think the argument probably would apply to the 2700 as well. The 2700 continues the same basic architecture. Anybody know?)

 

[cryoburner]

Anandtech has published an article detailing their findings and it's really quite interesting. Hopefully the folks at Tom's and other review sites are familiar with, or become aware of why Anandtech's benchmark numbers went the way they did.

Anandtech update

The gist of the matter is, Spectre and Meltdown mitigations decrease the performance of IO operations on Intel platforms. The HPET (High Precision Event Timer) is mapped in such a way, accessing it constitutes an IO operation. Forcing Windows to use HPET as it's primary timer has a major impact on Intel's CPU performance in cases where the software makes use of the timer. The difference hasn't been quantified between pre- and post-patched machines yet, but it's not an unfair assessment to say there won't be a performance difference, and the final result won't change anyway. HPET being used as the primary timer in Windows with a patched Intel system seems to come with a very high performance penalty.

The thing I found most interesting is that those who are overclocking their systems to get the most performance out of them, may in fact be installing software that changes a system setting resulting in lower performance, especially with Spectre and meltdown patches installed on an Intel platform. Having HPET forced on causes some significant performance hits in some of the games they tested. It might be nice if such software were updated to point this out, and maybe provide an option to check the HPET status and allow it to be turned off again.

TSC was just fine for this purpose before clock frequencies starting jumping around due to the introduction of technologies like SpeedStep and Cool'N'Quiet.

I encountered this with an Athlon64 system. Some older, mostly 90s-era games would directly read the TSC, and assumed it would remain at one rate throughout the program's operation. In the case of the Athlon 64, which brought dynamic frequency scaling to the desktop with Cool'n'Quiet, the TSC was directly linked to the processor's speed, and if the CPU dropped from 2.2 GHz to 1.0 GHz at idle, the rate of the TSC would also drop by more than half. So if a game measured the TSC at startup, when the CPU was under load, but then wasn't demanding enough to keep the processor at that speed during operation, the speed of the game could slow down, or fluctuate. In most games this wasn't a problem, and directly accessing the TSC had been discouraged for some years prior, but in certain older titles it could cause the game to run in slow motion, or mess with animations or other things. The solution was simply to keep the processor at full speed while playing the game, which could be done with a utility that puts a low-priority load on the CPU.

 

[R0GG]

Well: AMD is officially back in the ring, impressive come back.

 

[kinney]

This article should be dismissed entirely, the benchmarks for Intel are not Spectre v2 patched. AMD's are. If you're not going to update it with valid benchmarks, then remove the Intel results.

Just a PSA, this review is ONLY good for comparing Ryzen1 to Ryzen2.

 

[AgentLozen]

Hey my dude, this has been addressed several times in this thread. In the Tomshardware review of the Ryzen 5 2600x all of the benchmarks are run with Intel Spectre patches. You can view the results here: https://www.tomshardware.com/reviews/amd-ryzen-5-2600x,5579.html

Thanks for staying vigilant!

 

[kinney]

I read the articles, not everyone's comments- and it still needs to be addressed regardless. The Intel results need to be removed from this article.
If you're not going to do it right, don't do it at all. If those results from the 2600X review are valid and the same setup as here, then put them in this article.
No more of this sloppy journalism. Anandtech went back and updated their (valid) results with HPET disabled. These guys can be held to the same standard too. Downvotes won't dissuade me at all. I don't care who is butthurt, this is just the truth. Apples to apples or delete it.

*****It remains as of May 4th, 2018 that this review is ONLY good for comparing Ryzen1 to Ryzen2.*****

 

[ekremphotography]

Where is the premiere pro render and export benchmarks?

 

[Neuspeed]

So the i7-8700K still better for gaming than the 2700x.. Not surprised at all.. Business as usual..

 

[AgentLozen]

So the i7-8700K still better for gaming than the 2700x.. Not surprised at all.. Business as usual..

I wanted to reply with something sarcastic and point out a flaw in your thinking but this is pretty solid.

You expected the 8700K to be better in gaming than the 2700x. It was. You weren't surprised at all.

Soooo yeah. I've got nothing. Carry on.