AMD’s aggressive pricing update on the EPYC 7371

Re:AMD’s aggressive pricing update on the EPYC 7371 by gnulinux on Friday December 07, 2018 @08:23AM (#18627412)

But isn't the biggest customers of these chips are server owners? It's not like these companies/people will program the CPU itself and software support for Intel and AMD is exactly the same (is there anything that gcc can compile on Intel but not on AMD? Maybe one can argue the other way around due to recent security bugs, Spectre et al). So I can't see how this can be a factor.

[ Parent | on HN ]

Re:AMD’s aggressive pricing update on the EPYC 7371 by gabble on Friday December 07, 2018 @08:29AM (#18627444)

When it comes to servers its even more true as you're buying the platform as well as the CPU, the CPU is important to be sure but the platform features are even more so for running the hardware at scale.

A simple example, for a long time you couldn't PXE boot a server from a 10Gb NIC while using AMD chipsets. So every AMD system needed a 1Gb NIC cabled and maintained just to build the server vs a single 10Gb NIC on an Intel platform. That scales out for hundreds of servers now you need a 1Gb fabric and the associated switches etc just to allow you to build your systems.

[ Parent | on HN ]

Re:AMD’s aggressive pricing update on the EPYC 7371 by Hello71 on Friday December 07, 2018 @08:36AM (#18627494)

That, uh, doesn't sound right. None of your networking equipment can do auto-negotiation?

[ Parent | on HN ]

Re:AMD’s aggressive pricing update on the EPYC 7371 by jsight on Friday December 07, 2018 @09:07AM (#18627715)

I think that he meant that the workload still required the 10Gb link, so the AMD servers ended up with two NICs and two sets of cables (a 10 Gb connection and a 1 Gb connection). This leads to higher resource requirements, as they need effectively double the # of switches.

I'm not familiar with the problem at all, that is just how I interpreted his statements.

[ Parent | on HN ]

Re:AMD’s aggressive pricing update on the EPYC 7371 by bluGill on Friday December 07, 2018 @08:57AM (#18627639)

If you use an intel CPU you can use the intel compiler which in some workloads does a better job of optimization than gcc. The intel compiler doesn't know the right optimizations for AMD processors (at best, intel has been known to pessimize AMD processors).

Though overall you are correct that switching AMD to Intel is generally not a big deal, the above factors need to be accounted for.

[ Parent | on HN ]

Re:AMD’s aggressive pricing update on the EPYC 7371 by dkersten on Friday December 07, 2018 @10:06AM (#18628224)

> which in some workloads does a better job of optimization than gcc

Is this really true in a meaningful way? I mean, unless you happen to have an identical workload to the benchmarks?

I ask because the benchmarks and reports I've seen over the past ten years or so have really been quite disappointing in terms of icc's performance. I always assumed it must produce better performance code because its a proprietary product by the people who created the architecture and so they must know how to optimise for it, but from what I've seen, there's really not a big difference at all: some things icc has a slight lead and other things gcc does, but overall, they really don't seem to perform much differently. Unless you're making use of all the Intel libraries (Performance Building Blocks, Math Kernel Library, etc), in which case, I imagine they've tuned it for icc, there doesn't seem to be much reason to use icc especially since they've been known to pessimize for AMD cpus).

Am I wrong?

[ Parent | on HN ]

Re:AMD’s aggressive pricing update on the EPYC 7371 by celrod on Friday December 07, 2018 @11:34AM (#18629056)

I think icc's biggest advantage is automatically translating appropriate calls into calls to those performance libraries and linking them.

If you manually make calls in GCC, I bet you'd see similar performance much of the time.

icc also seems to more aggressively parallelize, even places you didn't ask it to.

[ Parent | on HN ]

Re:AMD’s aggressive pricing update on the EPYC 7371 by bluGill on Friday December 07, 2018 @11:24AM (#18628956)

Depends on your workload. A 1% difference between compilers can be very significant in a tight loop across a few thousand cores over several days. In other cases even a 100% difference wouldn't be noticed.

[ Parent | on HN ]

Re:AMD’s aggressive pricing update on the EPYC 7371 by simion314 on Friday December 07, 2018 @01:54PM (#18630427)

The Intel compiler is not testing for capabilities so it just not enabling optimizations for AMD CPUs, https://software.intel.com/en-us/articles/optimization-notic...

I am wondering why Intel is using images instead of text on that page, do they want to hide the information from web search ?

[ Parent | on HN ]

Re:AMD’s aggressive pricing update on the EPYC 7371 by jhasse on Saturday December 08, 2018 @05:17AM (#18634676)

According to https://www.agner.org/optimize/blog/read.php?i=49#49 it also checks the CPUID.

There was also a guy who benchmarked a Blizzard game in a VM where he changed the CPUID of his AMD CPU to an Intel one and received better performance than on the host (with GPU pass-through btw).

[ Parent | on HN ]

Re:AMD’s aggressive pricing update on the EPYC 7371 by simion314 on Saturday December 08, 2018 @09:50AM (#18635468)

Yeah, that is what I meant, the Intel compiler does not check if the compiler supports a feature or not, instead checks the CPU ID and apply optimizations for the specific compiler, but offcourse the AMD CPUs get no optimizations,

I was hoping someone would have an alternative reasons why those web-pages are images and no text or confirm my suspicion that is SEO related .

[ Parent | on HN ]

Re:AMD’s aggressive pricing update on the EPYC 7371 by jhasse on Saturday December 08, 2018 @10:10AM (#18635544)

Oh, I've missed the "not" in your previous comment, sorry ;)

[ Parent | on HN ]