Intel will likely respond with the minimum amount of changes that combined with their brand inertia will result in maximum revenue for them.
That, at first, will likely seem like the "rational" way to balance this "new competition" from AMD with keeping investors happy, but they're forgetting one thing -- in that equation the "brand inertia" they love to take advantage of is going to erode with each such "minimal response", until there is none or very little left.
What I'm trying to say is that consumers will put up with a company releasing sub-par/low-value products because they "trust the brand" only for so long, before they give in and start embracing the competition's brands -- as they should.
I mean, unless you, as a consumer, suffer from the Stockholm syndrome, you shouldn't be rewarding Intel for being forced to lower prices on some of its products or add more cores, just like you shouldn't have rewarded Comcast for offering fiber in places where Google Fiber arrived. You should be rewarding the competitor that caused that to happen -- that is if you'd still like that competition to continue in the future.
In Google Fiber's case, that competition disappeared because people were unwilling to reward it and stuck with Comcast/AT&T. And now they'll suffer from it for another decade or so, until another major disruption/competition appears (SpaceX satellites maybe?).
I love how you you are just making up some possible reaction by Intel, and then lambast them for that atrocious choice they did not make.
deleted 8y ago
[deleted]
This isn't completely made up. For example, in the desktop market AMD went from 4 cores to 8 to (rumored) 16 while Intel does 4, 6, 8, 10.
If you continue to post uncivil and/or flamewar comments, we are going to ban you. I just warned you about this.
https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
Excellent reply.
Intel has created a situation for themselves where they seem to have forgotten how to care about the purpose of innovation.
I'm not sure there are really viable alternatives. If all you need is a big CRUD database, sure there are alternatives, but there always were. Anyone buying Oracle for that was throwing money away. If your enterprise is more fully committed to the Oracle platform, or if you need a support model where you can open a ticket had have people working on it 24x7, possibly on-site, until it's resolved, then no, you can't just drop in PostGres or EnterpriseDB.
OT, but isn't the entire "per core" licensing scheme completely absurd for many products?
Since we know that in any significant system the effects of latencies in various cache hierarchies, buses, networks, storage, and cross process synchronization makes enormous difference in performance it's easy to see the CPU performance alone is not really a good predictor of system performance.
Thus, with a price calculated per CPU core the solution space narrows significantly, and experience tells us that solutions where per core licensing is involved tend to include expensive, hard to support networking and storage hardware which few would buy if not per core licensing had taken that option away.
If you want to charge per unit of work, then figure out how to do just that, and don't charge for what is effectively a theoretical peak unit of load?
AMD verified they would be running AVX2 at full clocks. Doing AVX-512 would happen at half-rate, but the processor would continue at full speed. In contrast, skylake downclocks base clocks by 30+%.
Not only does the AVX calculation downclock, but all the other calculations in other ALUs/FPUs also downclock. For pure AVX-512 workloads, Intel would be a little faster, but for mixed loads, AMD should be much faster overall.
AMD says they don't downclock AVX2 (about 2/5 down the page)
https://www.anandtech.com/show/13578/naples-rome-milan-zen-4-an-interview-with-amd-cto-mark-papermaster https://www.anandtech.com/show/13578/naples-rome-milan-zen-4...
See page 13 for AVX clockspeeds
https://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-scalable-spec-update.pdf https://www.intel.com/content/dam/www/public/us/en/documents...
My background is in the FPGA industry which gives an absolutely fantastic example of this exact dynamic. FPGA companies produce a new generation of chips every 3-5 years or so. There are only two companies, with market share split 60:40. In the last 2 decades we've seen one produce a fantastic product and the other screw up, and then it flips, and then it flips back. Over that time the market share of these companies went 60:40, 62:38, 58:42, 60:40. The actual number of customers who switch to the better product is tiny. Why?
* All the existing knowledge in the company is about one platform, it's incredibly expensive to develop the skills on the other toolchain. Port all your software etc.
* The existing products are all from one vendor so you save loads of effort if all the products are basically similar.
* There are existing relationships with the company you're with.
* You know that if you do switch, all that cost of switching may result in only a few years of using the better product.
* The IP you're buying works better with the vendor you're currently on.
* You don't know what the real world performance will actually be for your application.
So yeah, you could move from Intel to AMD, but the chip is only a tiny part of that cost.
Given the future doesn't look very bright for Intel, given ARM at one hand and AMD at the other (with their 10 nm and 7 nm having multiple setbacks) I wouldn't count on Intel doing well in the future. It might end up like Nokia or Microsoft. I wouldn't invest in Intel...
Umm Microsoft?
Latest news is that Intel's 7nm is doing quite well, and is on track to start high volume manufacturing in 2h 2019. And given that Intel 10nm is roughly comparable to TSMC 7nm, it's certainly possible that Intel will regain their process advantage very soon.
There are caveats in the above statement, but I certainly wouldn't bet against Intel.
I almost know zero about FPGA market but it seems that it's infinitely harder to port programs between FPGAs than from CPUs.
Other than that thanks for the insights, interesting facts.
That is probably generally true but if you have some serious compute workloads that you specialized for your server's CPU it could be hard to port between AMD and Intel as well. When people have customized the code for particular cache sizes, SIMD instruction sets, core counts, throttling schemes, ram throughput, and branch predictors and so on.
It's quite true, but what I've heard from FPGA users is that toolchain and conventions are aliens to each others, I think these are both two different kinds of hell. I don't know what would cost more to a company.
When you deliver an FPGA you’re normally also making your own hardware. That’s a big part of the FPGA porting cost, you have to redesign your boards. I don’t think the same is generally true in the x86 realm. Even if you’re specifically using some feature of the intel micro architecture it’s still essentially a code change rather than an full redesign.
Only when you design with unportable IP which the FPGA vendors are dying for you to design in. Some proprietary things like clock multipliers are unavoidable but they can be isolated in portable wrappers. Most FPGA devs are not this forward thinking and lock designs into a platform that makes future migration a problem. No different than writing code against Win32 vs Posix.
It is quite routine for ASIC development to prototype on FPGAs and that code will necessarily be made more portable to accommodate the architecture changes an ASIC requires.
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.
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.
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.
There are more than two companies.
I also work with FPGA (on the software side, but obviously I have a lot of interaction with the RTL people) and I think it's not entirely comparable.
Switching from an Intel x86-64 CPU to an AMD x86-64 CPU is absolutely trivial compared to switching between, say, a Xilinx Zynq SoC and an Altera Arria10 Soc (to take two chips I'm familiar with).
Switching from one FPGA to an other means changing all vendor-provided IPs (things like serializers/deserializers, encoders, decoders, MACs, DMA etc...), you probably have to change almost all your software stack, you need different tools, you need a different kernel, a different bootloader. You need to redesign your motherboards because obviously the pinout is different. And of course even beyond that it's never a 1:1 match it terms of capabilities, there are not always exact equivalents of one chip in the other vendor's inventory. So you may end up having to buy a more expensive chip to have the same number of memory blocks, I/O or whatever.
I think the main reason people are not switching to AMD en masse for servers is mainly inertia. The vendor lock-in is pretty tame compared to FPGAs.
This is especially apt since altera is now owned by Intel, and they're the one this generation that put out a dud.
I do work with FPGA's as well. The tool chains are a lot more tightly coupled to the device. Also IP tends to uses chip specific features a lot of times to get better performance or space utilization. So it's a lot harder to justify a switch. AMD's CPUs cover the cases of what intel provides 99% of the time.
Brand value, I guess? All AMD hardware (CPUs and GPUs) I've bought in the past was crap, I'm never buying anything from them again, no matter what they do. It's always the same: on paper they are better and cheaper, but once I have them at home they are worse and, in case of the GPUs, they have pathetic drivers. I've always felt ripped off after buying AMD, it's never worth it just to save some pennies.
This has been my experience, I wonder if others have felt the same.
I've had both Intel and AMD cpu's and both AMD and Nvidia GPU's (I guess you could add Intel too for their integrated gpu's) and my AMD experience has been generally quite pleasant and problem-free.
Whenever AMD's CPUs have been price/performance competitive they've always been a fantastic choice. Especially now, when with Ryzen/Threadripper/Epyc you not only got more cores for the less money, you also got better security.
AMD's GPU drivers have been perfectly fine since the 9700 Pro. That's a 16 year old myth at this point, let it go.
Its really not a myth, AMD drivers on windows have completely terrible openGL performance for instance.
Do you have any benchmark comparisons to support this claim? All I can find in searching are random threads of people saying this, but nobody providing any actual evidence or comparisons.
The few games using OpenGL on Windows I can find show AMD's performance being perfectly competent:
https://www.pcgamer.com/doom-benchmarks-return-vulkan-vs-opengl/2/ https://www.pcgamer.com/doom-benchmarks-return-vulkan-vs-ope...
https://www.hardocp.com/article/2014/05/21/wolfenstein_new_order_performance_review/4 https://www.hardocp.com/article/2014/05/21/wolfenstein_new_o...
The nvidia cards were on average a bit faster, but that was true in DX as well. Meaning it wasn't just "lol amd opengl drivers"
And of course Linux testing, where OpenGL is far more common, shows no major disparity, either, which you already know hence the qualifier of "on windows" but that qualifier makes no sense. It's going to be the bulk of the same code between windows & linux for the driver, as has also been rather well tested & verified.
Which gets back to "it's a goddamn 16 year old myth" that literally spawned out of Nvidia's hyper aggressive opengl optimization of Quake 3.
https://twitter.com/_humus_/status/1018846492273119233?lang=en https://twitter.com/_humus_/status/1018846492273119233?lang=...
ATI started rewriting their OpenGL driver in 2004-2007. Long after 9700 Pro’s prime.
As told by the author, it was a long lasting disaster.
Do you have an actual argument here? The story, while interesting, doesn't really contribute either way. Per the author's own story the switch to the new driver broadly didn't happen until after it was finally stable, and the legacy driver continued to receive performance optimizations in the meantime.
It's an interesting story of project management nightmares, but it doesn't provide any argument to the state of AMD's drivers as experienced by end users either way.
In terms of stability we do have some large-scale metrics on that front, such as Vista's crash blaming. Those metrics don't support claims that AMD's drivers are less stable than Nvidia's, as the Nvidia was responsible for 28.8% of Vista crashes while ATI was 9.3%. Given more Nvidia than ATI users that's not necessarily damning, but it also clearly disagrees with the notion that ATI is deeply unstable while Nvidia is rock solid.
And keep in mind during the 9700 Pro's prime all the way up to today OpenGL is used by nearly nothing on Windows. We're already talking about the niche use case.
It's probably more that they're clearing out the old chips before launching their 7nm-based Zen2 Epyc chips next quarter. They've already sampled out to hyperscalers.
But, generally, Epyc does have some deficiencies. It's essentially NUMA-on-a-package, and each NUMA node is itself essentially a pair of 4-core processors jammed together (each with its own cache, with all the usual problems that brings). That doesn't work for everything... for example GPGPU compute doesn't really like to be split across NUMA. Inter-core and memory latency is also much higher than on Intel platforms. Intel is playing with much larger building blocks, their die is 28C and they can scale up to 8 sockets, while AMD has 32C per package they can only scale up to 2 sockets because they are actually four dies inside already (both systems scale to 8 dies).
A lot of stuff is fine with those tradeoffs, particularly the stuff you use server processors for. And it's pretty cute if you want a lot of storage or lanes. And it's pretty cheap to manufacture due to their smaller dies (although of course TCO is much larger than just the cost of the CPU). But it's not for everyone.
Next quarter they're moving to 8 dies in a package, on 7nm, with updated AVX2 and probably support for the AVX-512 instruction set (at half throughput).
As others have pointed out, it's not entirely about Intel doing badly, but rather Intel putting out a mediocre performance and AMD finally really succeeding.
And while the various technical reasons for that are interesting, I do think that at least some of the credit/blame needs to go to the leadership. AMD had a string of bad leadership that led to the company to near bankruptcy, but then they hired Lisa Su, who is basically a superstar engineer-turned-manager who has excelled in everything she's touched, from doing very low-level transistor research to being the leader of large teams (and now the entire company). At the same time, Intel hasn't actually had a good CEO for a long while now, with the top leadership in the company chasing the latest fads and spending billions on weird acquisitions that only get written off later, while the key areas of the business are not doing nearly as well as they did under their predecessors.
Move aside, I'm an HPC administrator! :)
In the HPC world, things are not as clear cut benchmarks, or the vendors' own marketing materials/numbers.
First of all, the application you're running may be developed for a specific compiler, and the code sometimes depends on optimization behavior of a compiler. So, changing compilers changes a lot of things. This is why we have both Intel's tools, and GCC toolchain fully supported. For example, LAPACK and its siblings take compiler behavior and CPU specifications into consideration while compiling in an optimized way to maximize its performance IIRC.
Also, there's no guarantee that Intel's compilers are fastest on Intel hardware. In the days of Opteron 6100s, using Intel compilers, we were able to beat Intel processors of the same era. You heard it right: Compile using intel compiler with specific flags, run on AMD CPUs, get higher performance, profit!
Intel's AVX512 is well used and abused in HPC world, however AMD's HPC performance is not as bad as jandrewrogers implied in his comment [0]. AMD is originally an FPU company, and while their scalar instructions may lack on paper, they run really fast.
In HPC world, the CPU/board architecture becomes irrelevant after some point. SpecCPU benchmarks are the ultimate benchmarks, because their behavior is compiler agnostic and push every aspect of the CPU very very hard. If you can get the same SpecFP with an Intel part, you can get the more or the less same performance on real workloads.
If you have any other questions, you can AMA. I'll try my best to answer.
Funny addenda: We have some applications used widely by users, and when fully optimized, some older Intel CPUs outpace the newer ones by a significant margin. This is some heavy handed, exotic optimization.
[0]: https://news.ycombinator.com/item?id=18628592 https://news.ycombinator.com/item?id=18628592
> Intel's AVX512 is well used and abused in HPC world, however AMD's HPC performance is not as bad as jandrewrogers implied in his comment [0].
I know earlier AMD processors didn't actually have a 256-bit support, so AVX instructions were actually implemented by soaking up two 128-bit lanes (it helps that AVX doesn't have many instructions that actually permit you to move data between the two 128-bit slices of a 256-bit vector). For their AVX-512 performance to not be absolutely horrible, I take it they've actually built real AVX-512 units at some point?
From what I've read now [0], it looks like AMD still uses 2 x 128bit AVX units to execute AVX2 instructions. Also, AMD is always coming a generation behind Intel in terms of FP instructions sets, so Zen doesn't support AVX512.
According to WikiChip [4], Zen 2 actually has 256 bit FPU paths. I was unable to find a credible benchmark for Zen 2, so I can't talk about its performance. However, when analyzed from the perspective I've given below, it's not hard to assume that Zen 2 is a heavy hitter in terms of floating point performance.
However, the interesting part is, when you look to SpecCPU 2017 FP Rate [1], AMD Epyc 7601 [2] system has a similar per core performance with a much bigger Intel Xeon Platinum 8180 [3] system.
Why interesting?
* AMD's per core base (lowest) rate is 4.1875.
* Intel's per core base (lowest) rate is 4.3482.
* AMD is running GCC compiled code.
* Intel is running Intel compiled code.
* Intel has higher clock speed.
Intel has some CPUs (like Gold 5118, Gold 6148) which have per core base rate of ~5.125. These are the CPUs are considered as HPC processors, and used by a lot of people.
As I said before, it looks like Zen 2 is going to be a better HPC processor than Zen. Zen looks like a very good Enterprise processor now.
So with my hat, I can conclude that not having 512 bit hardware is not a crippling omission.
Addenda: I forgot to say that Intel has something called "AVX frequency". Since AVX, AVX2 and AVX512 has tremendous power requirements when compared to other operations, Intel lowers CPU to an undisclosed frequency. When I last checked, AVX frequencies of Intel CPUs that we use weren't in the technical guides and were not public in any way. So, the peak SpecFP Rate is not very different from the base ones.
Also, since the CPUs thermal budget is very constrained during AVXx operations, other ports' speed is also reduced. So at the end of the day, AVX512 is not a free turbo boost in HPC environments and heavy/continuous loads.
[0]: https://en.wikichip.org/wiki/amd/microarchitectures/zen#Floating_Point https://en.wikichip.org/wiki/amd/microarchitectures/zen#Floa...
[1]: http://spec.org/cpu2017/results/rfp2017.html http://spec.org/cpu2017/results/rfp2017.html
[2]: http://spec.org/cpu2017/results/res2018q4/cpu2017-20180917-08862.html http://spec.org/cpu2017/results/res2018q4/cpu2017-20180917-0...
[3]: http://spec.org/cpu2017/results/res2017q4/cpu2017-20171017-00119.html http://spec.org/cpu2017/results/res2017q4/cpu2017-20171017-0...
[4]: https://en.wikichip.org/wiki/amd/microarchitectures/zen_2#Key_changes_from_Zen.2B https://en.wikichip.org/wiki/amd/microarchitectures/zen_2#Ke...
A large part of the reason why AMD can reach similar sustained real throughput to Intel despite having a fraction of the FPU throughput is that they run the FPU as a separate unit on different issue ports, and their core is slightly wider when you measure the amount of instructions it can retire.
So even though the Intel CPU can in theory do 4x the computation AMD can in the vector units, in reality even the tightest real vector code does all kinds of things other than vector computation, in the middle of that vector stuff, like computing addresses for loads and stores and managing loop variables. On AMD, those intermixed scalar instructions go into separate scalar ports, on Intel CPUs they take space in the same issue slots that the vector code uses.
Then on top of that, the memory bandwidth is a great equalizer. Doesn't matter how many multiplies you can compute if you cannot load the operands, and the AMD systems are much closer there than they are in the pure computation, especially as they have a lot more L3 cache per core.
On Zen 2, AMD does two big things that are going to really help them in HPC loads. They are doubling vector unit width, and they are doubling the amount of L3 per core. I honestly think the second change will help more than the first.
You're right. Also Intel's AVX implementation is very power heavy, and they need to lower CPU frequency to fit into their thermal budget (see "Addenda:" in my previous comment).
Also yes, AMD's memory subsystem has much lower latency, and has higher bandwidth. Also their direct-attach approach is better than Intel. I forgot that advantage TBH :)
However, I can argue about L3s effect on speed. In some cases, the code and the data is so small, but the computation is so heavy that, you can fit almost everything into the caches. I had a 2MB binary which required 200MBs of memory at most, but it completely saturated the CPU in every way imaginable.
So, in some cases caches have great affect on speed. Especially if the data you're invalidating and pulling in is huge. However, if the circulation is slow, a faster FPU always trumps a bigger cache.
> Also yes, AMD's memory subsystem has much lower latency
Out of interest, what do you mean by this? Are you talking Zen1 or Zen2, because in my experience playing with Zen1 EPYC the memory latency was worse than Xeon Broadwells, and on top of that you had worse NUMA issues that could affect certain cores which weren't directly attached to the memory and this added additional latency more than on the Xeons I was comparing against.
They're doing the same thing they are now with AVX2, but with AVX-512. So 512b instructions will translate into two uops.
It's still useful to implement the AVX-512 instructions because they fill in some holes in the existing AVX instruction sets (eg lack of scatter/broadcast instructions) and implement a new SIMT-like op-masking functionality.
> They're my favorite instructions too, and I really hope Zen2 fixes their performance problems.
Me too. AFAIK their slowness is probably due to requiring a specialized functional unit to implement. Something like the unit described in this paper [1].
> Allegedly, Intel improved the integer-division instruction to ~20 clock cycles on the 9000-series
Do you have a reference?
That would be weird if it applied only to the 9000 series, and not other Coffee Lake cores. After all, it's the same core, reportedly unchanged all the way back to Skylake [2], so how could the divider be faster?
FWIW, even for Skylake, Agner reports 26 cycles for a 32-bit idiv, so the chip is already close (if you were talking 32-bit division).
> Even then, AVX2 code is more efficient to decode and run. So even if its emulated on AMD's platform, there are benefits to writing AVX2 code.
Yes, that's why I said you _might_ make _some_ different decisions, such as in any algorithm that doesn't scale cleanly to 256 bits, but still ends up faster when the CPU offers full 256 bit ALUs (so 256 bit and 128 bit ops have the same performance).
One real-world example would be something that uses a vector-width lookup table, say for a shuffle mask. With 2 possibilities for each DWORD element, a 128-bit shuffle mask only needs 16 entries, but 256-bit masks need 256 and they are twice as large (8 KiB in total!). With fast 256-bit units you might suck up this penalty, since it might end up faster overall, but with 128-bit units you might be better off going with the much smaller table and 128-bit lookups, at the same total throughput.
> Remember that its not a pure win on Intel systems either: use of any YMM register begins to downclock the whole chip,
Well not really anymore. Most (all?) recent chips don't downclock for use of 256-bit registers (not counting "high lane powerup"). Only some server chips downclock for "heavy" AVX2 use, which really means a lot of back-to-back FMAs or other heavy FP operations. In general the penalty for 256-bit instructions is small on recent cores (a larger penalty is paid for AVX-512), and compilers generally use them freely (the same is not true for 512-bit) and effectively.
---
[1] https://github.com/tpn/pdfs/blob/master/Fast%20Bit%20Compression%20and%20Expansion%20with%20Parallel%20Extract%20and%20Parallel%20Deposit%20Instructions%20-%202006%20(hilewitz06).pdf https://github.com/tpn/pdfs/blob/master/Fast%20Bit%20Compres...
[2] I think there must be some small changes, since the LSD was re-enabled, implying that they fixed the bug where registers could be corrupted when using the high half of the GP byte registers.