News Intel Brings Its Own Benchmark to Refute AMD's '2X' EPYC Claim

[bit_user]

according to the intel slide "hyperthreading:ON 1thread per core"

Yeah, this is funny because running just 1 thread per core effectively nullifies HT. There's still potentially some benefit to having it enabled, in case the kernel or some background job wants to run something in parallel, but you're basically getting negligible advantage from it.

BTW, there's some hypothetical scenario in which HT can actually harm performance, but I've not seen this in any real-world benchmark since Intel brought back HT in the first-gen i-series CPUs. By that time, they had clearly learned a lot about where the feature created problems, in the Pentium 4.

 

[bit_user]

The Cooper Lake 14nm 48 core/96 thread chip will add two more memory channels and support for higher speed memory. Also will add bfloat16 avx512 support. wikichip shows it with pcie4 support, although I haven't seen an intel announcement yet. This is supposed to be sampling this year, so need to run the benchmarks again to see if the extra features boost it over the amd 64 core chip.

Of course new chips should be benchmarked, but bfloat16 most likely won't help this benchmark. And they're already using other AVX512 instructions, here.

Also, keep in mind that the extra memory channels might be reserved for Optane DIMMs.

The avx512 is shared between threads. Apps that use it are trying to keep it filled. I've read ai performance recommendations that say turn off hyperthreading and use core affinity assignments to guarantee consistent high performance from these.

Well... the entire core is shared between hyper-threads. AFAIK, only AMD's Bulldozer architecture had any kind of weird FPU sharing between cores. Thankfully, that's now all behind us.

The affinity guidelines might've concerned programs where you have some threads using AVX512 and other threads that don't. In such cases, you'd want the AVX512 threads evenly distributed over the cores, and paired with other threads that aren't using it, instead of being paired up with another thread that's also trying to use it.

 

[bit_user]

Except AMD has not had 99% of the server market nor the majority of the desktop market for the past 10 years. Intel is a bigger target thus more vulnerabilities.

Dude, what? I mean, seriously what?

The same security researchers and cloud operators looking at Intel CPUs are also looking at AMD and ARM CPUs! If you're aware of any evidence that they're subjecting Intel CPUs to any more scrutiny than the others, please share. I've yet to see any favoritism, because the reality is these findings are feeding into their near-term purchasing and configuration decisions. So, if Intel has a vulnerability, they want to be sure that AMD is not subject to a comparable exploit, as this would affect whether they buy AMD systems or whether those systems (also) need mitigations. They don't want to simply switch from one insecure CPU to another.

The more share AMD gets, the larger they get the more targeted they will be and the more we will see coming for them as well.

It's long been said that malware more often targets the more common platforms, but these exploits are not being discovered by examining malware, so your point really doesn't apply.

I have to conclude you're either confused or dissembling. Neither puts this post in good light.

it looks like their tests were done on Linux which has been affected differently than Windows.

No, not really. You see, these are vulnerabilities deep in the microarchitecture of the actual CPU - it's not an OS-level thing. The main point of difference is which mitigations one OS uses vs. the other.

Also, Linux isn't just one thing. There's the matter of which distro, which kernel version, and how it's compiled.

 

[amir.zabin]

by what ive seen in this forum, almost nobody reads the footnotes of any released promotion pictures, so i guess ill take my leave before investing a lot of time into this discussion

 

[bit_user]

by what ive seen in this forum, almost nobody reads the footnotes of any released promotion pictures, so i guess ill take my leave before investing a lot of time into this discussion

There's a potential conflict between Intel's disclaimer that not all publicly available security patches might be applied, and the article claiming that it is patched.

As this was a report from a presentation at trade show, maybe the claim of having all the security patches was either mentioned during the presentation or came out during a Q&A period. So, I'd like Paul to cite why he believes Intel's kernel is fully patched.

 

[EpicAnchor]

Except AMD has not had 99% of the server market nor the majority of the desktop market for the past 10 years. Intel is a bigger target thus more vulnerabilities.

As well Intel is not the only one with the flaws. While Intel does have more AMD has been affected as well as has VIA.

The more share AMD gets, the larger they get the more targeted they will be and the more we will see coming for them as well.



I have not seen anything stating it does or does not have patching. However it looks like their tests were done on Linux which has been affected differently than Windows.

Clearly you weren't around in 286 days. When Intel tried to squash AMD. After they bailed them out with IBM. Since that time Intel has spent tonnes of money trying to get rid of the company. If not for AMD, Intel may not exist as it is today. A lot money has been spent to sink AMD. Including finding vulnerabilities. Nobody (in the CPU business) has been under a microscope more than AMD.

 

[bit_user]

Clearly you weren't around in 286 days. When Intel tried to squash AMD. After they bailed them out with IBM. Since that time Intel has spent tonnes of money trying to get rid of the company. If not for AMD, Intel may not exist as it is today. A lot money has been spent to sink AMD. Including finding vulnerabilities. Nobody (in the CPU business) has been under a microscope more than AMD.

Yeah, let's not forget the shameful incident early last year, with CTS Labs and AMDFlaws.com.

CTS Labs' AnandTech Interview Raises More Questions About Its AMD Vulnerability Disclosure

The saga of CTS Labs' revelation of 13 (potential) vulnerabilities in AMD's Ryzen and EPYC processors continues.

www.tomshardware.com

AFAIK, nobody established that Intel had direct ties to that incident, but it sure was a case of someone specifically gunning for AMD. And, just to be clear, the flaws cited were 3rd Party (i.e. ASMedia) chipset-level issues, many of which also affected Intel boards (a fact not mentioned by CTS Labs).

 

[Star Pilgrim]

BUT !!!!

When Intel applies all the security fixes needed for their shitty CPUs, regardless of hyper-threading, AMD Rome still beats it a lot.

Those multi million dollar contracts it got is not simply based on some online journalists benchmarks. They do professional considerations in-house to determine which CPU platform is best for them.

Intel can cry like a little B"##$, but it won't change the fact that they need to pick up the pace and get their affairs in order, both price wise, power consumption wise and performance wise.

 

[jimmysmitty]

Clearly you weren't around in 286 days. When Intel tried to squash AMD. After they bailed them out with IBM. Since that time Intel has spent tonnes of money trying to get rid of the company. If not for AMD, Intel may not exist as it is today. A lot money has been spent to sink AMD. Including finding vulnerabilities. Nobody (in the CPU business) has been under a microscope more than AMD.

I was young. And it was not just AMD it was also VIA whom Intel tried to "squash". However whats in the past is in the past.

There has also been a lot of money spent to keep AMD alive. However if you look at it the worst period of AMDs timeline was their own doing, not Intels doing or any other companies doing.

Dude, what? I mean, seriously what?

The same security researchers and cloud operators looking at Intel CPUs are also looking at AMD and ARM CPUs! If you're aware of any evidence that they're subjecting Intel CPUs to any more scrutiny than the others, please share. I've yet to see any favoritism, because the reality is these findings are feeding into their near-term purchasing and configuration decisions. So, if Intel has a vulnerability, they want to be sure that AMD is not subject to a comparable exploit, as this would affect whether they buy AMD systems or whether those systems (also) need mitigations. They don't want to simply switch from one insecure CPU to another.


It's long been said that malware more often targets the more common platforms, but these exploits are not being discovered by examining malware, so your point really doesn't apply.

I have to conclude you're either confused or dissembling. Neither puts this post in good light.


No, not really. You see, these are vulnerabilities deep in the microarchitecture of the actual CPU - it's not an OS-level thing. The main point of difference is which mitigations one OS uses vs. the other.

Also, Linux isn't just one thing. There's the matter of which distro, which kernel version, and how it's compiled.

OK.....

I wont say I am 100% sure but I would assume they focus on the more used hardware. I would consider that a some of these exploits have been around for quite a while, they affect some much older CPUs as well, that the focus is more on Intel. Am I saying AMD has a ton of exploits? No. But is it possible that they have multiple that have yet to be discovered since they are not as heavily used? Absolutely.

Let me clarify what I meant by it affecting Linux differently. I meant in terms of the patching to fix said exploits. I know they are hard built into the CPU itself. Which is why the best solution is hardware fixes vs software patches. However since the kernal is different Linux might handle the fixes better or worse.

As for which kernel they were using, since these are data center focused products I would assume, again assume not know, they would use a linux distro that is commonly used in these markets.

This is why I hate when companies try to show their products against others instead of allowing third parties do it.

 

[jeremyj_83]

Why the Intel Xeon Platinum 9200 Series Lacks Mainstream Support

We break down why the Intel Xeon Platinum 9200 series lacks mainstream support from major OEMs and is focused as a niche x86 HPC compute density platform

www.servethehome.com

Intel cannot give the 9000 series away. There are no OEMs even offering it right now. No one wants the 9000 series.

 

[TJ Hooker]

The Intel kernel? According to whom?

What distro did they use - Intel's own Clear Linux, perhaps?

They explicitly state which distro + kernel were used for each Intel test system in the configuration slide posted in the article. If you google the kernel version you can find the Red Hat release notes for the kernel, which list any CVEs addressed.

 

[bit_user]

However if you look at it the worst period of AMDs timeline was their own doing, not Intels doing or any other companies doing.

Well, it's true that Bulldozer was a bit like AMD's Pentium 4. But we really can't know what would've happened if AMD had more resources, at the time.

I actually think a lot of Intel's lead since Sandybridge was due to their manufacturing leadership. It's no accident that AMD couldn't finally catch them until they got back on a competitive node. I'm of the opinion that Intel should've been forced to divest its manufacturing arm, since that gave it an unfair market advantage. However, much like how you attributes AMD's woes to its own missteps, Intel's loss of manufacturing leadership was its own doing.

As for which kernel they were using, since these are data center focused products I would assume, again assume not know, they would use a linux distro that is commonly used in these markets.

Oh, you really can't assume anything, with these benchmarks. AMD said which distro & major kernel version it's using. As it turns out, Intel also said what they used - I was just looking for that info in the wrong part of the slide.

This is why I hate when companies try to show their products against others instead of allowing third parties do it.

But they always will. So, your only option is to wait until it ships and then see where the chips fall.

 

[bit_user]

They explicitly state which distro + kernel were used for each Intel test system in the configuration slide posted in the article.

Thanks. I was looking in the wrong part of the slide. Credit to Intel for listing the specific build, as well.

I think it's interesting, but not necessarily significant, that they used 3 different Linux distros (and kernel versions).

If you google the kernel version you can find the Red Hat release notes for the kernel, which list any CVEs addressed.

But 3.10 kernels? That's pretty ancient. It's nice that one can, but did you actually check which patches those have? I can't say I care enough to invest the time...

...though, the 8280 notes suggest it has at least some.

 

[jeremyj_83]

Thanks. I was looking in the wrong part of the slide. Credit to Intel for listing the specific build, as well.

I think it's interesting, but not necessarily significant, that they used 3 different Linux distros (and kernel versions).


But 3.10 kernels? That's pretty ancient. It's nice that one can, but did you actually check which patches those have? I can't say I care enough to invest the time...

...though, the 8280 notes suggest it has at least some.

Actually 3.10-957 is the most current kernel on Red Hat 7.6
https://access.redhat.com/articles/3078#RHEL8

 

[jimmysmitty]

Well, it's true that Bulldozer was a bit like AMD's Pentium 4. But we really can't know what would've happened if AMD had more resources, at the time.

I actually think a lot of Intel's lead since Sandybridge was due to their manufacturing leadership. It's no accident that AMD couldn't finally catch them until they got back on a competitive node. I'm of the opinion that Intel should've been forced to divest its manufacturing arm, since that gave it an unfair market advantage. However, much like how you attributes AMD's woes to its own missteps, Intel's loss of manufacturing leadership was its own doing.


Oh, you really can't assume anything, with these benchmarks. AMD said which distro & major kernel version it's using. As it turns out, Intel also said what they used - I was just looking for that info in the wrong part of the slide.


But they always will. So, your only option is to wait until it ships and then see where the chips fall.

Even before Bulldozer AMD had their own issues. I would say Phenom (K10) was their Pentium 4 with Bulldozer being their Pentium Extreme. Before any of that AMD, when they were selling every last chip they could pump out (Athlon 64), they closed one of their two FABs down hampering production. They then proceeded to purchase ATI for well over their worth just before Core came out, which is where Intel jumped ahead again. Then came Bulldozer which just did not deliver when Intel was pushing pretty hard.

If Jim Keller didn't leave and Hector didn't take the reigns we might have had K12 after the flop that K10 was instead of Bulldozer and maybe they would have done better. Who knows.

Of course you can't assume but it turns out I was not far off.

Intel tends to not compare to AMD when presenting new products, normally. They might have at times. They normally present it in comparison to their previous products which makes more sense. I understand why AMD compares to Intel to try and win customers but I have never seen a cross competition comparison that has ever panned out after third parties get their hands on it.

 

[TJ Hooker]

Thanks. I was looking in the wrong part of the slide. Credit to Intel for listing the specific build, as well.

I think it's interesting, but not necessarily significant, that they used 3 different Linux distros (and kernel versions).


But 3.10 kernels? That's pretty ancient. It's nice that one can, but did you actually check which patches those have? I can't say I care enough to invest the time...

...though, the 8280 notes suggest it has at least some.

I did glance through the notes for the kernel used in the 9282 test, it lists the 4 CVEs that pertain to the "Zombieload"/"Fallout" vulnerabilities.
https://www.redhat.com/archives/rhsa-announce/2019-May/msg00054.html
https://en.wikipedia.org/wiki/Microarchitectural_Data_Sampling

Given that I think those are the latest vulnerabilities it would make sense that it would have all the previous ones, but that would probably take some digging to confirm.

I agree that it is a little curious that they use different kernels for each test.

 

[jimmysmitty]

I did glance through the notes for the kernel used in the 9282 test, it lists the 4 CVEs that pertain to the "Zombieload"/"Fallout" vulnerabilities.
https://www.redhat.com/archives/rhsa-announce/2019-May/msg00054.html
https://en.wikipedia.org/wiki/Microarchitectural_Data_Sampling

Given that I think those are the latest vulnerabilities it would make sense that it would have all the previous ones, but that would probably take some digging to confirm.

I agree that it is a little curious that they use different kernels for each test.

I don't see 3 different kernels but 3 different distros. The 9282 used RedHat 7.6 on Kernel 3.10-957.12.2.el7_x86_64. The 9242 used CentOS 7.6 but the same kernal and the 8280 used Oracle Linux 7.6 on a 7.5 kernel with the same Linux kernel. The only difference was the distro which may or may not make any difference in workload performance.

I would think it might have to do with hardware certification? Per Oracle they have a HCL list that is certified hardware for their distro. Its also possible Intel is working with Redhat and CentOS to get support for the 9000 series in those OSes and Oracle will certify any servers themselves or possibly wont support them at all.

 

[TJ Hooker]

I don't see 3 different kernels but 3 different distros. The 9282 used RedHat 7.6 on Kernel 3.10-957.12.2.el7_x86_64. The 9242 used CentOS 7.6 but the same kernal and the 8280 used Oracle Linux 7.6 on a 7.5 kernel with the same Linux kernel. The only difference was the distro which may or may not make any difference in workload performance.

9282 uses kernel 3.10.0-957.12.2.el7.x86_64
9242 uses kernel 3.10.0-957.5.1.el7.x86_64
8280 uses kernel 3.10.0-957.5.1.el7.crt1.x86_64

All right there in the slide. No idea what significance (if any) those slightly different version names have though.

 

[jimmysmitty]

9282 uses kernel 3.10.0-957.12.2.el7.x86_64
9242 uses kernel 3.10.0-957.5.1.el7.x86_64
8280 uses kernel 3.10.0-957.5.1.el7.crt1.x86_64

All right there in the slide. No idea what significance (if any) those slightly different version names have though.

Was hard to read but you are correct. Might be the recent versions for those specific distros.