[HN Gopher] AMD server CPUs capture highest market share gains f...
___________________________________________________________________
AMD server CPUs capture highest market share gains from Intel in 15
years
Author : giuliomagnifico
Score : 218 points
Date : 2021-05-09 17:10 UTC (5 hours ago)
(HTM) web link (hothardware.com)
(TXT) w3m dump (hothardware.com)
| reph2097 wrote:
| Stonks to the moon
| [deleted]
| ketanmaheshwari wrote:
| It will go down if I understood the recent market trends
| correctly.
| [deleted]
| Judgmentality wrote:
| It will go up if I understood the recent market trends
| correctly.
| katbyte wrote:
| It will change if I understood the recent market trends
| correctly.
| snovv_crash wrote:
| It will stay the same...
| nimbius wrote:
| And, in my opinion, its only going to get worse if Intel doesnt
| sober up and address the elephant in the room: Hyperthreading.
|
| Without serious reform to the design of the Intel X86 chip to
| eliminate and refactor what basically amounts to a performance-
| before-safety feature, Intel is going to see the lions share of
| performance hits. Eventually people will tire of writing backflip
| code to sidestep pitfalls in the Intel HT design and simply
| return the responsibility to Intel, where its existed since day
| one.
|
| It could be argued Intels mouthpiece has already lost its ability
| to convince major datacenter and cloud customers that HT is even
| remotely safe as a continued investment. Intel needs a new X86.
| josteink wrote:
| Doesn't AMD also provide hyper-threading of sorts?
|
| My Ryzen has 6 cores and 12 threads. Isn't that pretty much the
| same?
| altusbrown wrote:
| Something about the AMD implementation is notably harder to
| exploit, though last I looked it wasn't clear what that was.
| It's held up much better, and a lot of people have looked at
| it.
|
| Still exploits, but almost impossible to do in the field last
| I checked, where Intel has been demonstrated on live systems
| handling production load.
| to11mtm wrote:
| It's difficult to say why AMD's implementation has held up
| better. One interesting thing I noted looking at wikichip's
| info [0] was that Zen calls out that Cache is tagged by
| thread. I wonder whether Intel's HT did/does the same or
| not.
|
| [0] https://en.wikichip.org/wiki/amd/microarchitectures/zen
| #Simu...
| rwaksmunski wrote:
| I heard somewhere that AMD speculated a bit less and cleaned
| up a little after a miss, which made exploitation a lot more
| difficult. I'm sorry I don't recall the source, might have
| been an interview with one of AMD's engineers.
| tomerv wrote:
| What exactly is the connection between hyperthreading and
| safety?
| bayindirh wrote:
| HT enables some side-channel attacks due to its architecture
| of "let's allow two threads to share the same pipeline and
| use the unused parts to allow more work to go through".
|
| In practice this allows some attacks to attach themselves to
| the same pipeline with the target process and nibble required
| information slowly, but surely.
|
| IIRC FreeBSD disabled HT out of the box at the kernel level
| for this reason.
|
| I'm tired and it's late here. I may worded some stuff wrong
| or plainly misremembered it. Please feel free to correct.
| 0xy wrote:
| What's stopping more people from moving cloud workloads to AMD?
| Unless you're running a rickety legacy application using Intel
| features you'll instantly save money by moving to AMD.
|
| Both my work and all my side projects have moved to AMD instances
| where available, except for some legacy on-prem stuff.
| kcb wrote:
| We've had a company wide call to switch to AMD instances
| wherever possible. It's generally a straight 20% cost savings
| and most instances are usually overprovisioned anyway.
| davidkuennen wrote:
| I actually already switched my Kubernetes cluster to the new
| AMD CPUs in GCP and it's running fantastically. Couldn't be
| happier with the performance.
| croutonwagon wrote:
| For those of us running VMware
|
| Licensing is a part. VMware moved to per core licensing a while
| ago and away from per socket.
|
| The other part is some limitations with mixed architecture
| clusters. Things like DRS and vmotion will be gimped.
|
| The third part is lead times.
| schaefer wrote:
| Can you be more specific? Or provide a citation?
|
| VMWare workstation 16 Pro is still has a flat price,
| regardless of core count [1].
|
| [1]: https://store-us.vmware.com/vmware-
| workstation-16-pro-542417...
| croutonwagon wrote:
| https://www.vmware.com/company/news/updates/cpu-pricing-
| mode...
|
| https://4sysops.com/archives/vmware-moving-to-per-core-
| licen...
|
| Workstation isn't used in the enterprise. That's gonna be
| vsphere and esxi.
| wdb wrote:
| That's a consumer product
| baybal2 wrote:
| By "capturing" a client, many companies _unwittingly become
| captive to the client_.
|
| By having clients who can't run away from you, you often limit
| yourself to the tech you can sell to them, instead of pursuing
| new superior alternatives.
|
| Cisco, Oracle, SAP, IBM -- all great examples of this.
| chrischen wrote:
| I run infrastructure for my startup and previously was "locked
| in" because of AWS reserved instances that may come with multi-
| year tenancies. However recently I committed to some new
| generation AMD instances, but Graviton (ARM) were serious
| contenders.
| atdrummond wrote:
| Not the case for everyone but I've had instances (and again, I
| recognize this is an edge case) where AMD was more expensive
| due to per-core software licensing.
| dvfjsdhgfv wrote:
| It's a quite common theme actually and I'm very curious how
| it plays out for the companies insisting on per-core
| licensing in the long term. I mean, if the customers have no
| choice, they'll stay, but I bet they're looking into some
| exit strategy in order to stay competitive.
| i_have_an_idea wrote:
| for me, it costs money to make sure that my CPU-intensive
| workloads run the same or better, the gains probably aren't
| huge, so it's just not worth it
| walrus01 wrote:
| > What's stopping more people from moving cloud workloads to
| AMD?
|
| It's not just about CPU bound workloads but also things that
| are heavily I/O dependent (typically on bare metal hardware
| that you own, rather than instances you rent somewhere).
| There's lots of networking and storage things that would be
| performance bottlenecked on an intel cpu with less PCI-E lanes.
| Having a 16-core CPU around $950 that has 128 PCI-E 4.0 lanes
| is very useful for many things.
|
| And not just for EPYC but also the single socket threadripper
| parts, which are used in both higher end workstations and some
| types of server.
| ixfo wrote:
| 100% this. With NVMe and higher bandwidth NICs, fast and
| plentiful PCIe lanes are increasingly important and Intel
| have just been so far behind in this (or gated equivalance at
| hilarious price differentials from AMD - like having to go to
| $4k Intel parts (and beyond) to match AMD prosumer desktop
| parts).
| bayindirh wrote:
| Just try to attach a 8 GPU A100 unit to a 2P Intel system,
| then try to add fast Infiniband with NVMe for scratch, and
| whole platform just chokes.
| 0x000000E2 wrote:
| ^^ this is huge. I was looking at CPU's for a ML recently and
| Intel is out of the question. Chips with enough lanes to hit
| full speed on 4 GPUs + SSD cost twice as much as AMD.
|
| This may even apply to high end gaming machines. Soon as you
| have 2 SSD's or video cards you will exceed link budget on
| most Intel CPU's and everything slows down.
|
| It also happens to routers. 10 gig NICs plus attached SSD
| storage, over link budget again.
|
| Intel's stupid market segmentation is biting them in the rear
| walrus01 wrote:
| Not just 10Gbps (such as the Intel card which is four
| 10Gbps SFP ports in one slot), but single and dual 100GbE
| per slot like this:
|
| https://www.intel.com/content/www/us/en/products/docs/netwo
| r...
|
| In calculating the bandwidth and pci-e bus throughput
| needed, a single 100GbE port is full duplex, so one has to
| budget about 210Gbps per port.
|
| The funny thing is that some of the best 100GbE NICs for
| x86-64 servers on the market right now are _Intel_ , but
| are best used on an AMD platform...
| 9front wrote:
| Intel's E810 based NICs require only a PCIe3.1x16 slot.
| 16 lanes will accommodate the 100GbE port just fine.
| Theoretical PCIe throughput for 16 PCI lanes is around
| 252Gbps. The 800 NIC chipset is just four 25Gb Ethernet
| lanes stitched together. PCIe4 won't help this NIC much.
| chx wrote:
| Nah, PCIe is also full duplex you don't need to double it
| like that but Mellanox has dual 200gbe cards. Here's the
| PCIe 3.0 version: https://cdn11.bigcommerce.com/s-uxkkta8
| o/images/stencil/1280... and here's the PCIe 4.0 version:
| https://cdn11.bigcommerce.com/s-uxkkta8o/images/stencil/1
| 280...
|
| Yes, the 3.0 version needs two PCIe x16 slots.
| drewg123 wrote:
| What? Why do you think the Intel 100GbE NIC is good?
|
| We've been quite happy with Mellanox and Chelsio 100GbE
| NICs. The latest from each can do in-line HW TLS offload,
| which is a killer feature for us. No Intel NIC can do
| that.
|
| IMHO the last good Intel NIC was the 10GbE "ixgbe" NIC.
| The design of the NIC was so tight as to be almost
| beautiful.
|
| Recent 40GbE (and 10GbE based on the 40GbE chipset), and
| the new 100GbE NIC have the feel of being designed by a
| committee with endless features of questionable value
| stuffed in and consuming power and chip area.
| walrus01 wrote:
| Primarily the state of its Linux driver, and rock solid
| support in VyOS (derived from Debian stable). For a
| router, TLS offload isn't so much of a consideration when
| the system isn't doing anything at layers 4-7 in the OSI
| model.
|
| If I had to make a perhaps overly broad generalization, I
| see more Chelsio and Mellanox NICs used in end point
| servers, and more Intel used in DIY whitebox network
| equipment.
| drewg123 wrote:
| That's fair; I come at this from a CDN perspective where
| end system performance is most important.
|
| Do you see any benefit from the fancy features? Can it
| source/sink min sized frames at 100GbE? (144Mpps) ?
| jeppesen-io wrote:
| For the workloads I manage, the AMD instances are the same or
| slower per $ than comparable Intel instance families (m5/m5a
| and r5/r5a). Those use the 1st gen Epyc AFIK
|
| Regardles, when third generation epyc Milan rolls out to AWS
| this year or next, the wave of movement to AMD will be massive
|
| For c5a in us-east-1, it's simply not offered in all the AZs
| we've been assigned
| CodesInChaos wrote:
| At least on AWS the AMD CPUs seem to be clocked pretty low, so
| assuming the IPC is similar to Intel, the performance/cost
| benefit of AMD seem pretty small and comes with downsides for
| tasks that benefit from single core performance.
| dvfjsdhgfv wrote:
| It's one of the reasons the so-called desktop CPUs are so
| popular for certain applications. [0]
|
| [0] https://jan.rychter.com/enblog/cloud-server-cpu-
| performance-...
| my123 wrote:
| Server CPUs everywhere are lowly-clocked compared to client,
| except some specialty ones (F series for AMD, Xeon-W among
| other lines for Intel).
|
| High clocks come at the detriment of power efficiency, so
| they are avoided when possible.
| CodesInChaos wrote:
| An M5 is a "3.1 GHz Intel Xeon(r) Platinum 8175M" ($0.192
| for xlarge)
|
| while an M5a is an "AMD EPYC 7000 series processors with an
| all core turbo clock speed of 2.5 GHz" ($0.172 for xlarge)
|
| which is only about 10% cheaper. But the claimed clock is
| 20% lower. Different IPC or sustained clock might shift the
| balance a bit, but it seems unlikely that AMD wins
| decisively on performance/cost.
| techrat wrote:
| "AMD EPYC 7000 series" is so vague as to be almost
| meaningless... so we need more info there.
|
| The 8175M's base clock 2.5Ghz, with a Turbo (all core) of
| 3.1Ghz and (one core) 3.5Ghz.
|
| > assuming the IPC is similar to Intel
|
| Using your assumption as a criteria... the Platinum 8175M
| should perform the same as an AMD EPYC 7763, whose base
| clock is also at 2.5Ghz with 3.5Ghz top Turbo speed. This
| is the only EPYC part that keeps nearly the exact same
| clocks as the Platinum at every stage.
|
| But we know the IPCs aren't equal, so I don't even know
| why you'd mention that when discussing your comparison
| when it's so fatally flawed from the start.
|
| Even using something as rudimentary as Passmark
| highlights the difference.
|
| 8175M Single Thread Rating on Passmark: 1903
|
| EPYC 7763 Single Thread Rating on Passmark: 2639
|
| So, clock for clock where the speed stages area
| identical, AMD wins.
|
| Going through the list of every Eypc 7000 series part I
| could find, the one that turbos at or near 2.5Ghz is the
| 7551... first gen part and only hits 2.55Ghz when it's
| all core turbo.
|
| EPYC 7551 Single Thread Rating: 1813.
|
| Performance difference ratio of single thread rating
| between EPYC 7551 vs Platinum 8175M: 0.95270625328
|
| Cost difference ratio of EPYC 7551 vs Platinum 8175M:
| 0.89583333333
|
| Looks like AMD is still the more cost effective solution
| here.
| wtallis wrote:
| I think you may be comparing single-core turbo against
| all-core turbo speeds. ark.intel.com doesn't list the
| 8175M, but all the similar models have 2.1GHz all-core
| turbo with single-core turbo around 3.7 or 3.8 GHz. Other
| sources list the 8175M as having a base frequency of
| 2.5GHz and single-core turbo of 3.5GHz.
| flatiron wrote:
| Personally I run a plex server and that one piece of hardware
| I've kept intel because of qsv. Amd has no answer for that.
| That one workload is 100% intels wheelhouse.
| llama052 wrote:
| We have been slowly changing over to AMD instances on Azure,
| it's not a huge savings but it's enough to justify it unless
| you have a specific need for certain CPU types or licensing.
| bluedino wrote:
| I can't mix and match my VMware clusters with Intel and AMD,
| you lose features like vMotion
| bayindirh wrote:
| > What's stopping more people from moving cloud workloads to
| AMD? Unless you're running a rickety legacy application using
| Intel features you'll instantly save money by moving to AMD.
|
| Nothing. Unless you're explicitly targeting AVX-512, you don't
| miss anything. Just move the systems and continue where you
| left.
|
| Furthermore, first Epyc sold so fast that, it was virtually
| impossible to buy in large quantities since Dropbox, FB and
| Google just bought the whole production out, IIRC (we weren't
| able to buy it, and no big IT vendor sold it under their
| generally available server lines).
| rwmj wrote:
| There's a surprising amount of lock-in for corporate customers.
| They'll be using proprietary software which is only certified
| for Intel (for reasons which can sometimes be real). They could
| be using the Intel compiler which as far as I know still
| pessimizes on AMD. Also it's not necessarily cheaper to move
| your workloads to AMD if that involves buying new hardware (if
| on-prem) and retesting everything or having to go to all your
| software suppliers to check if they support AMD.
|
| Personally I switched to AMD hardware a couple of years ago and
| haven't looked back, but corporations don't do that.
| 0xy wrote:
| I suspect large customers are going to AMD for a quote, and
| then taking the quote straight to Intel for them to beat. No
| transition headache and price benefits with that approach.
|
| But those are on-prem customers, what about cloud customers?
| In the SOA world, surely greenfield stuff won't be using any
| of that proprietary Intel software.
| headmelted wrote:
| I think you've hit the nail on the head here. I also think
| you may have answered your own question.
|
| Cloud customers may be taking volume quotes to Intel from
| AMD to see what they can/will do for them on price. I don't
| see why they wouldn't do that, what with their (way out of
| the normal range) buying power.
| bushbaba wrote:
| Cloud is skipping amd and going straight to ARM.
|
| I suspect AMD is getting a bigger chunk of a smaller pie as
| ARM makes headwind.
| matwood wrote:
| Exactly. I moved some workloads to AMD, but with
| Graviton2 out now I'm going straight to it where I can.
| reitzensteinm wrote:
| Who except for Amazon is doing this currently? Or are you
| forecasting a long term trend.
| lostlogin wrote:
| If AMD are being used to drive down prices, it has a good
| overall effect though doesn't it?
|
| And if AMD get the feeling they are being used this way,
| offering quotes with no margin will make for painful days
| at Intel.
| selectodude wrote:
| Intel's margins are almost certainly higher than AMDs.
| adgjlsfhk1 wrote:
| Probably they were 4 years ago, but I'm not so sure now.
| Intel's processors require about 2x as much silicon per
| core (14nm vs 7nm), so if they are priced similar per
| core, Intel is probably getting squeezed.
| djbebs wrote:
| The silicon costs are a very tiny portion of their cost
| of goods sold.
|
| Electricity, water and even just plain packaging of the
| cpu will likely cost more than the difference in silicon
| use between 14 and 7 nm
| robocat wrote:
| 1. The cost difference between 14mm2 and 7mm2 is a whole
| new fab at twice the density (assuming transistor count
| remains the same). Asset costs _really_ matter to Intel.
|
| 2. If the constraint on the number of packages you can
| sell is the number of chips you can produce, then the
| packaging cost of the chip is not so relevant (assuming
| packaging is not a constraint on production). If you can
| halve the chip area on the same production node, you can
| double production of packages, which can make a huge
| difference to profits (assuming Intel is a high margin
| business with high demand and that demand elasticity is
| in their favour etcetera).
|
| Disclaimer: I am not in the industry, but what you say
| just seems wrong without even arguing that the cost of
| the silicon for Intel dominates packaging costs.
| gogopuppygogo wrote:
| A trend likely to continue in the short term but remember AMD
| still cannot create enough product to fulfill demand.
| reph2097 wrote:
| What makes you think so?
| elorant wrote:
| Just look at the prices for the Ryzen lineup. They've gone
| like 100% up in the last year because AMD can't meet demand.
| baumy wrote:
| I've been wanting to build a new desktop with a 5950x ever
| since it came out, and have been completely unable to find
| anybody who has it in stock except for scalpers at a 30%+
| markup. This is fairly well known information.
| seizethegdgap wrote:
| Not sure what your usecase is, but I bought a used 3950X
| for $633 (with tax) in January to use for a homeserver
| build. You could buy an X570 mobo and a used 3950X for now,
| and upgrade to the 5950X if you decide you need it.
| 0x000000E2 wrote:
| Buy from Europe. Seriously, most stores will ship to US.
| The ones without English UI have better stocks.
|
| I have been able to buy everything I've looked for at
| normal retail from European stores
| _JamesA_ wrote:
| MicroCenter[0] has been receiving stock for in-store
| purchase only.
|
| Antonline[1] has them in stock for shipping in a bundle
| with a Lenovo gaming monitor.
|
| [0]: https://www.microcenter.com/product/630282/amd-
| ryzen-9-5950x...
|
| [1]: https://www.antonline.com/Lenovo/Computers/Computer_Di
| splays...
| magicalhippo wrote:
| Seems to be in stock at least three places[1] here in
| Norway, at a relatively reasonable price given the $799
| price from AMD.
|
| But yeah, of those that have it in stock there's like 1-5
| units at each place, and those out of stock don't have a
| firm date on next delivery...
|
| [1]: https://prisguiden.no/produkt/amd-ryzen-9-5950x-469899
| fiddlerwoaroof wrote:
| This is just the general chip shortage problem, right?
| mlyle wrote:
| There's two flavors of the chip shortage problem:
|
| 1. TSMC leading-edge process is the hottest (coolest,
| really ;) process and just not enough capacity to meet
| all the demand for mobile, high end desktop, GPUs, etc.
| This predates the main shortage we're talking about.
| Cryptocurrency mining is a contributor to this one, too.
|
| 2. There's a broad shortage of parts made on less
| cutting-edge processes. Causes: disruption to production
| from COVID, disruption from automakers churning orders,
| increased demand for consumer products, and
| speculation/hoarding.
|
| Of course, #2 made #1 even worse.
| jrockway wrote:
| I think that everyone building their own computer has to
| compromise something right now. I couldn't find any ECC
| when I built my machine last year, so I live without it. It
| sucks, but global pandemic and all. Next time around it
| will be better. As much as we hate scalpers driving up the
| price of computer parts, the cost does translate to
| availability. So you can pay $2000 and have the latest
| thing right now, and maybe between when the price drops
| $500 because of increased availability you will have earned
| more than $500 because of the increased productivity. Or,
| maybe no amount of performance will make you $500, and you
| just want a $35 Raspberry Pi to cut your losses.
|
| (Once you're willing to spend $2000, you might as well just
| get a 3970 and have twice as many cores, if you can
| tolerate higher latency in exchange for higher throughput.
| I have a 3970 and definitely benefit from the throughput
| more than I would benefit from lower latency, even if it's
| quite noticeable. For example, some games are bottlenecked
| by the CPU, which is annoying. But, if you want consistent
| 360 fps in every game, you're spending an infinite amount
| of money for no financial gain anyway, so the cost-based
| reasoning goes out the window.)
| pedrocr wrote:
| Indeed, but the race between TSMC and Intel to scale up 200+
| MTr/mm^2 processes should benefit us all. Both AMD and Apple
| have good micro-architectures to produce at TSMC, and Intel is
| mostly behind on process, so if we can keep that race going
| maybe we can still have ~2x performance every ~2 years for a
| while longer. I'm looking to switch laptops and was surprised
| to find out that after 5 years and as many generations I can be
| right on track for that performance growth.
| chmod775 wrote:
| > maybe we can still have ~2x performance every ~2 years for
| a while longer
|
| At no point in the past 20 years did we even come close to
| that.
|
| You're probably thinking of Moore's Law, which refers to
| transistor count, not performance.
| pedrocr wrote:
| I'm thinking of actual benchmarks. Here's the one I've been
| looking at:
|
| https://www.cpubenchmark.net/compare/AMD-
| Ryzen-7-PRO-4750U-v...
|
| The top CPU choice for my current Lenovo T460s was the
| i7-6600U. Exactly 5 laptop generations later the top CPU
| choice for the T14sG2 is the Ryzen 7 5850U. The ratio of
| performance between those two is 5.82. That's 42% per year
| or almost exactly 2x every 2 years on the same form factor
| and TDP. Last year's 4750U was at 4.4x after 4 years.
|
| Intel has only been able to do 1.6x every 2 years in the
| same comparison. Their single core performance is
| comparable but they've only been able to deliver 4 cores
| versus AMD's 8.
| mlyle wrote:
| CPUMark is a flawed benchmark, but.. in 2004 the average
| score was 385 on Desktop. In 2012, it was 4626. So-- that's
| 12x in 8 years, vs. 16x from doubling every 2 years. I'd
| say we used to come close.
|
| For the past 5 years, it's been doubling about every 3
| years.
| SahAssar wrote:
| ~
| Tuna-Fish wrote:
| > 2004: 385
|
| > 2005: 770
|
| > 2006: 1540
|
| You are doubling every year, not every two years.
| SahAssar wrote:
| Ah, you're right! Thanks
| christkv wrote:
| I would think the chiplet strategy that AMD used is also a
| benefit compared to Intels more monolithic design when it
| comes to yields.
| lumost wrote:
| I am curious how much of the process delay in Intel came
| from having chip design and manufacturing under one
| umbrella.
|
| If AMD wanted the latest process they had to deal with the
| limits TSMC said they could achieve. Intel's chip team
| could simply push back on their manufacturing team to
| improve reliability via leadership.
|
| If Intel had gone with chiplets would 10nm have been
| delayed?
___________________________________________________________________
(page generated 2021-05-09 23:00 UTC)