The Ampere Altra Review: 2x 80 Cores Arm Server Performance Monster
anandtech.com
anandtech.com
"Intel’s current Xeon offering simply isn’t competitive in any way or form at this moment in time."
The rest of the paragraph twists the knife more, and declares there to be an open market on server hardware for AMD and Ampere to fight it out.
With application stacks being what they are and optimizations for Xeon so deeply integrated, it's unlikely that folks running private datacenters actually feel the same way, but if I was spinning up a new company with the sort of funding to be able to decide between self-hosted or cloud I would have some math to do.
If the expansion and replacement will mostly involve AMD and ARM-based solutions, I won't be surprised.
Of course Xeons are going to stay for a relatively long time, because some customers are deeply invested in them, e.g. relying on AVX512 heavily, etc.
I also don't think that Intel is going to go under. AMD was in the position of a second-rate player for decades, and had expensive failures, too (remember Bulldozer?). So I expect them to regroup and show us something amazing in, say, 5 years. But one thing they are.going to lose: their sweet big margins.
In part AMD broke out of this by using TSMC, but Intel relying on (not just using) TSMC would be a huge step.
https://www.extremetech.com/electronics/317329-tsmc-will-ope...
Not sure if it has to be absolutely top-tier for defense purposes though.
OTOH you'd rather be top-notch in your communication equipment, low-power sensors for reconnaissance, etc. In some areas, having a US-controlled 7 nm fab may matter even for DoD.
Intel's optimization guide alone is about 1000 pages long, AMD's isn't as good and they've been at it for decades now.
If you have the money Intel aren't as competitive any more, but for the middle ground where you don't have the budget to bring up your own software it's not the same calculus.
Also you really have to grind your teeth to get past AnandTech's habit of comparing, on a performance-per-dollar basis, just whatever CPU that happen to have laying around. The entire reason the Xeon Platinum costs $10000 is because it scales to 8 sockets, a level needed only by people who have backed themselves into a corner with Oracle or SAP and who now need a gigantic single host at any price. Anyone who was actually planning to build a 2-socket server would choose the Xeon Gold 6258R with the same core count, the same cache, higher clocks, and less than half the price. Suddenly when you make a comparison to a comparable product, you find that Intel has the cheapest product of the three, along with certain favorable performance aspects.
What? That makes so little sense. Is this chip x86 or something? Because the architecture is a pretty big deal for me when I decide which chip to invest in.
AMD and Altra are trading blows at the high end of performance, as seen in this article, while Intel is... not, except in extremely specialized applications.
Intel servers don't even offer PCIe 4.0 at this time, which is just a bad joke when it comes to building out servers with lots of high performance storage and networking. For now, Intel offers (relatively) poor CPU performance and poor peripheral performance.
So, if your software can't run on Altra, the other choice for high performing servers is AMD, not Intel, unless you're just locked into Intel for historical reasons.
Intel does have some nice budget offerings for cheap servers, though, such as Xeon D.
So Amazon made a huge mistake with Graviton then? Last time I checked Amazon 'specify, buy, and operate servers at scale'.
Regardless, the claim that there is no value in Intel let alone x86 is a stretch.
Platinum is crazy priced for a crazy reason: its a building block to truly massive computers that only IBM matches. Supercomputers don't even typically use Platinum: Platinum is for the most vertically-oriented systems.
---------
Xeon Gold is your more typical 2-socket or 4-socket machines: same performance, but fewer sockets supported.
Both AMD Epyc Rome and Ampere Altra can support 8TB of RAM in dual socket machines, so that spec isn't particularly impressive anymore.
> Platinum is crazy priced for a crazy reason: its a building block to truly massive computers that only IBM matches.
Meh. A dual-socket Rome system with 128 cores (256 threads), 8TB of RAM, and 128 PCIe 4.0 lanes is an enormous machine. A full 8 socket Platinum system is going to cost an order of magnitude (or two) more, and the performance improvement is going to be less than 2x.
An 8-socket system is going to consume an enormous amount of power, cost an unbelievable amount of money, and the complex NUMA domain combined with Intel's interconnect isn't going to "just work" for almost any software, so you're likely going to put a lot of effort into making that system barely work.
Intel Platinum is priced crazy because Intel is building monolithic processors (which means low yields) and Intel likes to have a substantial profit margin. Together, those mean high prices.
At a certain point, you're better off investing in making your application work on an accelerator of some kind, in the form of a GPU or an FPGA or task-specific ASIC, rather than giving Intel all your money in the hopes of eeking out a marginal performance improvement. Alternatively, finding software that can scale to more than one machine.
Maybe IBM has truly large systems that are worth considering. Intel doesn't right now, unless you're using some software that demands Intel for contractual reasons no one can argue with.
I was doing the specs from memory and conservatively: 128GB sticks across 48-channels.
https://www.supermicro.com/en/products/system/7U/7088/SYS-70...
This 8-way Supermicro system supports 192x DIMMs. So... 128GB sticks x 192 == 24TBs of RAM or so, maybe 48TBs.
> At a certain point, you're better off investing in making your application work on an accelerator of some kind, in the form of a GPU or an FPGA or task-specific ASIC, rather than giving Intel all your money in the hopes of eeking out a marginal performance improvement. Alternatively, finding software that can scale to more than one machine.
I mean, these 8-way systems are what? $500k ? Less than $1MM for sure. How many engineers do you need before a machine of that price is reasonable?
Really, not that many. If you can solve a problem with a team of 10 engineers + 48 TBs of RAM, that's probably cheaper than trying to solve the same problem with 30 engineers with a cheaper computer.
-----------
> An 8-socket system is going to consume an enormous amount of power, cost an unbelievable amount of money, and the complex NUMA domain combined with Intel's interconnect isn't going to "just work" for almost any software, so you're likely going to put a lot of effort into making that system barely work.
NUMA scales better than RDMA / Ethernet / Infiniband. A lot, lot, LOT better.
All communications are just memory-reads, and that's a real memory read. Not an "emulated memory read transmitted over Ethernet / RDMA pretending to be a memory read". You incur the NUMA penalty but that's almost certainly better than incurring a PCIe penalty.
But for that bandwidth to be used efficiently, the processes on each NUMA node need to almost exclusively limit themselves to memory attached to their node -- at which point, well-written software could probably do just as good spread out over several machines that are connected by multiple 100Gb network links, and then you saved two or three bajillion dollars.
If you're heavily using the bandwidth over the NUMA interconnect, then you're not going to be using the memory bandwidth very effectively (and likely not really using the processor cores effectively), and that's when NVDIMMs like Optane Persistent Memory could give you large amounts of bulk memory storage on a smaller system.
Or just use a number of Intel's new PCIe 4.0 Optane SSDs in a single machine in place of the extra memory and memory channels... the latency isn't the same as RAM, but it's much closer than traditional SSDs, and the bandwidth per SSD is like 7GB/s, which is impressive.
It all depends on the application at hand, but there are solutions that cost a lot less than the Platinum machines for virtually every problem, in my opinion.
I don't know... perhaps I'm too cynical of these cost-ineffective systems that just happen to be large, and I should be more impressed.
> NUMA scales better than RDMA / Ethernet / Infiniband. A lot, lot, LOT better.
Disagree.
Wait, so latency over NUMA is too much, but you're willing to incur a 100Gb network link? Intel's UPI is like 40GBps (Giga-BYTEs, not bits) at sub 500ns latency.
100Gb Ethernet is what? 10GBps in practice? 1/4th the bandwidth with 4x more latency (in the microseconds) or something?
That's a PCIe latency penalty (x2, for the sender + the receiver). That's a penalty for electrical -> optical, and back again.
Any latency, or bandwidth, bound problem is going to prefer a NUMA-link rather than 100Gbps over PCIe.
The point is not just the latency, but latency and bandwidth.
If the application is relying heavily on the NUMA interconnect to transfer tons of data, it's not going to be making efficient use of the processor cores or the RAM bandwidth. It's a total all around bust. You're just wasting money at that point. ^1
If you aren't relying heavily on the NUMA interconnect, and each node is operating independently with only small bits of information exchanged across the interconnect, then you'd save a metric ton of money by switching to separate machines and using just high speed fiber network links -- such as 100Gb.
I'm not saying that network would be better than the NUMA interconnect. I'm saying that you're not going to be having a happy day if you're relying on the interconnect for large amounts of data transfer.
The only situation where the NUMA set up is better is if you have a need for frequent, low latency communication between NUMA nodes... where very little data is being transferred between nodes, so the entire problem is just latency.
At that point, you're still suffering a lot by the NUMA interconnect, and it would be better to use larger processors... such as Epyc Rome processors.
So you really have to be in a very obscure situation which can't fit onto a dual socket Rome server, but can fit within a machine less than 2x larger. (28 cores * 8 sockets is less than 2x larger than 64 cores * 2 sockets)
You see how complicated this is and how absurdly niche those Platinum 8-socket machines are? They're almost never the right choice.
^1: The exception is if you have an even more niche use case that somehow is built for exactly this scenario in mind, and manages to balance everything perfectly. Such a software is almost certainly ridiculously overcomplicated at this point.
If the interconnect is your bottleneck, you spend money on the interconnect to make it faster. Basic engineering: you attack the bottleneck.
You don't start talking about slower systems and how they're cheaper. Because that just slows down the rest of your system.
------
If you just wanted cores, you buy a 28core Xeon Gold. The point of 28-core Xeon Platinum is for the 8-way interconnect and scaling up to 8-way NUMA systems. The only person who would ever buy a Xeon Platinum is someone who wants 40GBps UPI connections at relatively low latencies. (or maybe even the 300GBps connections that IBM offers, but that's a similar high-cost vertical-scaling system)
> So you really have to be in a very obscure situation which can't fit onto a dual socket Rome server, but can fit within a machine less than 2x larger. (28 cores * 8 sockets is less than 2x larger than 64 cores * 2 sockets)
That's not even that hard to figure out! A 48TB Memcached / Redis, which is far more useful than a 8TB Memcached / Redis box.
A bit basic, but yeah. That's the point: spend more money on hardware and then don't spend much engineering time thinking about optimization. If 48TBs of RAM solves a problem that 8TB cannot, then just get the 48TB system.
If you need more than 8TB of RAM, with the right application design you can probably do better with fast Optane Persistent Memory or Optane SSDs, and an effective caching strategy. You can have many dozens of terabytes of Optane storage connected to a single system, and Optane is consistently low latency (though not as low latency as RAM, obviously).
If you need more compute power, you can generally do better with multiple linked machines. You can only scale an 8-socket system up to 8 sockets. You can link way more machines than that together to get more CPU performance than any 8 socket system could dream of.
----------
I didn't expect you to read and respond so quickly, so I had edited my previous comment before you submitted your reply.
This was a key quote added to my previous comment:
>> So you really have to be in a very obscure situation which can't fit onto a dual socket Rome server, but can fit within a machine less than 2x larger. (28 cores * 8 sockets is less than 2x larger than 64 cores * 2 sockets)
In response to your current comment,
> If the interconnect is your bottleneck, you spend money on the interconnect to make it faster. Basic engineering: you attack the bottleneck.
Exactly. Using a dual-socket Epyc Rome system would be more than half as powerful as the biggest 8-socket Intel systems, but it would reduce contention over the interconnect dramatically, which means that many applications that are simply wasting money on an 8-socket system would suddenly work better.
This also goes back to my comment about using accelerators instead of an 8-socket system.
The odds of encountering a situation that just happens to work well with Intel's ridiculously complicated 8-socket NUMA interconnect, but can't work well over a network, and can't work well on a system half the size and requires enormous amounts of RAM to keep the cores fed, the odds seem vanishingly small... and in that case, we still have to consider whether an accelerator (GPU, FPGA, or ASIC) could be used to make a solution that is a better fit for the application anyways, and if so, you'll save large amount of money that way as well.
So, to make buying an 8-socket system make sense, the application must require performance that is...
- less than twice a dual socket Epyc Rome system, but greater than one dual socket Epyc Rome system can handle
- not dependent on transferring huge amounts of data around the interconnect
- dependent on very low latency communication between NUMA nodes
- needs enormous memory bandwidth for each NUMA node
- needs huge amounts of RAM on each memory channel (so you can't just use HBM2 on a GPU to get massive amounts of bandwidth, for example)
- etc.
It's a niche within a niche within a niche.
As I said in an earlier comment, I probably should be more impressed instead of being so cynical about the usefulness of such a machine. They are engineering marvels... but in almost every case, you can save money with a different approach and get equal or better results.
That's why 8-socket server sales made up such a small percentage of the market, even before Epyc Rome came in and completely obliterated almost all of the very little value proposition that remained.
But I also know that in-memory databases are a thing. Nothing I've touched personally needs an in-memory database, but its a real solution to a real problem. A niche for sure, but a niche that's pretty common actually.
Whenever I see these absurd 8-socket designs with 48TBs of RAM, I instinctively think "Oh yeah, for those in-memory database peeps". I never needed it personally, but its not that hard to imagine why 48TBs of RAM beats out any other architecture (including Optane or Flash).
Agree to disagree.
In-memory databases are common yes, but it is pretty hard to imagine practical situations where an in-memory database can't handle a few nanoseconds of additional latency.
All else being equal, of course more RAM is nice to have. All else is not equal, though, so this is all highly theoretical.
But it is fun to think about!
8-socket CLX nets you 1.75x the cores, and 3x as many memory channels vs. a 2-socket Rome system. It also scales to a single system image with 32 sockets if you use a fabric to connect smaller nodes:
* 4-socket nodes: https://www.hpe.com/us/en/servers/superdome.html
* 2-socket nodes: https://atos.net/en/solutions/enterprise-servers/bullsequana...
That's 48tb of DRAM with all 128gb DIMMs, or 12tb+128tb when using 512gb Optane PDIMMs.
> That's not even that hard to figure out! A 48TB Memcached / Redis, which is far more useful than a 8TB Memcached / Redis box.
No... dozens of terabytes of Optane would be just as good and much much cheaper. The person designing the system would have to prove that a few nanoseconds of latency difference makes any material difference to the company's profits in order to justify the more expensive machine. Otherwise, it's a huge waste of company money, hurting the business.
Also keep in mind that Redis is only going to be using a single core of that machine. A total waste of huge amounts of CPU cores just to have a lot of RAM, when there are equally good solutions that cost much less.
You surely must see why I'm skeptical.
> That's the point: spend more money on hardware and then don't spend much engineering time thinking about optimization.
It's bad business practice to buy the most expensive thing possible instead of engineering a solution that is the right price. If the more expensive solution saves money in the long term, sure... but your example doesn't show this.
PCIe Optane is orders of magnitudes slower than DDR4. In both bandwidth and latency.
The only Optane that keeps up to DDR4 (kinda-sorta) is the Optane DIMMs which are exclusive to Xeon Golds / Platinum systems.
It’s only slower if someone can observe the difference, which I don’t think they would be able to in this design.
I’m a strong proponent of using fewer, larger machines and services, instead of incurring the overhead involved in spreading things out into a million microservices on a million machines. But there is a balance to be achieved, and beyond a certain point... synthetic improvements in performance don’t show up in the real world.
Queuing up a few database requests concurrently to make up for the overhead of literally hundreds of nanoseconds of latency is trivial, especially when Optane can service those requests concurrently, unlike a spinning hard drive. Applications running on other machines won’t be able to tell a difference.
But, agree to disagree.
There are probably applications where these mega machines are useful, but I don’t personally find this to be a compelling example.
I readily admit that I could be wrong... but neither of us have numbers in front of us showing a compelling reason for a company to spend unbelievable amounts of money on a single machine. My experiences (limited compared to many, I’m sure) tell me this isn’t the winning scenario, though.
$500k on a machine isn't a lot of money compared to engineers. Even if you buy 4 of them for test / staging / 2xProduction, its not a lot compared to the amount spent on programming.
It’s possible for them to both be independently expensive, and I’m saying that unless you can prove that the performance difference makes any difference to company profits, it is literally a huge waste of company money to buy those expensive machines.
A lot of applications will actually perform worse in NUMA environments, so you’re spending more money to get worse performance.
Reality isn’t as simple as “throw unlimited money at Intel to save engineering time.” Intel wishes it was.
Engineering effort will be expended either way. It is worth finding the right solution, rather than the most expensive solution. Especially since that most expensive solution is likely to come with major problems.
I think that would be very exciting because they have the engineering expertise and talent necessary to compete against Apple's M1. I don't know of any other company that can do that (besides Intel, but you know...).
Additionally, there is a huge hole open right now for ARM on everything else that is not an Apple product. Apple normalized ARM on consumer's desktops/laptops: they brought down the "subjective" barrier against ARM, which is much harder to break sometimes than the technological one.
But ARM CPUs for everything else that is not an Apple product is up for grabs. The M1 is extremely competitive but it will never leave Apple's realm (unless Apple wants to start competing on the CPU business, but I see that going very strongly against Apple's consumer focus).
It is incredible, looking at it in retrospective, but Apple opened up (or normalized, if you will) a whole new market for ARM products.
a. They start investing now and they can have some leverage in the spec.
b. The spec is minimal and open to expansion that it sets itself up for more domain specific processors. Which we will be seeing alot more of thanks to the slowing of transistors per dollar growth.
c. There is a pretty big theme of moving toward more open and democratized standards in tech.
d. They would be the big dogs in RISC-V where as ARM already has big players.
e. In both ARM and RISC-V they would be saving the need for extra transistors. My understanding is that there are extra transistors that basically translate x86 machine code to some internal RISC ISA for performance reasons on x86 processors. Due to the slowing of transistors per dollar growth and the maturation of external Fabs Intel and AMD will no longer be able to 'hide' this deficit.
f. No royalties
This paper refutes your point and is inline with my understanding: https://carrv.github.io/2020/papers/CARRV2020_paper_12_Perot...
One counter point is the simpler the ISA the more work the compiler needs to do. So x86 is may be easier to write an optimize compiler for given it does some of the work for you (despite the bloat).
I wonder how much benchmarks on the current ARM and RISK-V chips will change over time due to compiler improvements. ARM probably already has alot of investment in some workloads...
EDIT: This presentation show code size comparisons with a RISC-V extension that adds multiply/divide and it get really close to ARM: https://riscv.org/wp-content/uploads/2019/12/12.10-12.50a-Co...
With compression and the multiply/divide extensions very similar to the ARM-M Thumb variants in code density.
https://riscv.org/announcements/2016/04/risc-v-offers-simple...
https://riscv.org/wp-content/uploads/2019/12/12.10-12.50a-Co...
Really fun time to be working on this part of the stack.
But for 64-bit, ARM has dropped support for Thumb, while RISC-V still supports compressed instructions. In that case, RISC-V is more dense than ARM. I can't find the numbers for that right now, but I read it just yesterday so I'm pretty sure I remember correctly.
Also keep in mind that Thumb is a mode that the ARM CPU has to switch to, while RISC-V compressed instructions can be mixed with normal instructions.
Having said that, I hope AMD doesn't decide not to develop a RISC-V CPU. I'd expect them to have the resources to start working on ARM now, while planning for RISC-V further out.
Yes, companies (Apple especially, but also Samsung and Qualcom) have been making optimized ARM CPUs, but those designs remain within those companies. Very similar optimizations could be made on a RISC-V implementation and AMD has proven that they have the ability to make design optimizations.
I doubt that strategy would work. The problem in the PC space is that there's no Apple-like leader who can boldy drive a change in CPU architecture. Whoever is first out of the gate bears all the risk of the change not catching on. If you lose the bet, you've wasted massive R&D spend to make a lemon. Take a look at the reviews of Microsoft's ARM surface laptops to see what I mean here.
I think there's an opportunity over the next 5 years or so for PC makers to ride the M1's coattails and shift from x86 to ARM. Especially given intel's failure to move off 14nm. But I doubt lightning will strike twice. If windows moves to ARM now, we'll be stuck there for at least another few decades. And the technical argument for RISC-V will be much weaker if ARM rules the roost.
Weirdly the strongest counterargument I can think of is due to electron. Chrome will maintain first class support for any and every popular CPU architecture. So the more that desktop software is written on the web and in electron apps, the easier any architecture transition will be down the road. That and the server space. Linux already supports RISC-V extremely well given how few linux-capable RV chips there are in the wild.
Possibly the makers of Pine64 and Raspberry Pi could cooperate and offer something in this area, because they collectively control most of the market of hobby / general-purpose ARM system boards. If they set a common standard (or even two standards), other producers in this space would have an incentive to follow. This will simplify OS porting efforts enormously.
BIOS provided tables allow you to enumerate devices that aren't on the PCI bus, and BIOS provides methods to interact with storage devices. UEFI does all the same things, but differently.
A lot of ARM64 boards intended towards general purpose use include UEFI these days.
Exynos didn't even manage to be the fastest ARM CPU in a Chromebook. The Tegra K1 was a bit quicker.
My (Celeron) Chromebook 2 supported a whole Linux VM (via Crostini) and using Vim for python and Go development on it was noticeably slower than any contemporary laptop - I can't imagine the Exynos version was far off on perf (since it was only a diff SKU). I would not call it "terrible".
The M1 is a nice product. But let's not pretend it's the first ARM device in the world. It has plenty of merits to rest on that it don't need that qualifier as justification, anyways.
I don't think apple was really all that special in this regard. They were ahead of the curve, which is impressive, but the market was created by arm, not just apple. I doubt we'd be seeing this kind of resurgence had others - especially google - not also jumped on the ARM bandwagon. A rising tide lifts all boats; both android and ios likely benefited from each others shared usage of arm because it helped the whole ecosystem.
For some sense of scale: qualcomm's latest chip just released some benchmark numbers, and while they're not all that impressive (https://www.anandtech.com/show/16325/qualcomm-discloses-snap...) it's still good to put "not that impressive" in perspective: they're comparable to i7-6700k in single-threaded workloads, and to an i7-4770k in multi-threaded workloads. The oldest iPhone that runs the same geekbench version I can find is the iPhone 5s, which is a little more than 4x slower in the single-threaded benchmark, and 8x in the multi-threaded. Yet that chip was no slouch!
Obviously, apple's impressive pole position completely hogs the spotlight, but it's worth remembering that the competition isn't actually all that bad. That level of performance would make for an extremely fast chromebook - were it not for the fact that most are cheap cheap cheap and will never use a high-end chip.
Development across the board has been so fast, that if you remember slow ARM chromebooks, I think you attribute that slowness to 2 things other than apple vs everybody else: firstly, they were built to a bargin-basement price, and thus you weren't getting anything near this performance not because it wasn't apple, but simply because they didn't use the right chips in the first place, and secondly, it's been a while, and when things improve that quickly, then a slightly outdated model can easily appear terrible without that being a condemnation of the whole approach.
Not really. Look at the difference between Apple's "little" cores and the stock ARM "little" core.
>The performance showcased here roughly matches a 2.2GHz Cortex-A76 which is essentially 4x faster than the performance of any other mobile SoC today which relies on Cortex-A55 cores, all while using roughly the same amount of system power and having 3x the power efficiency.
https://www.anandtech.com/show/16192/the-iphone-12-review/2
Apple's Icestorm "little" cores are in the same performance ballpark as the big cores in the Qualcomm variant of a Galaxy S10.
That's a night and day difference.
And here, the numbers just don't back up the claim that apple is running rings around qualcomm in terms of performance. Not just that; the difference between apple+qualcomm chips hasn't changed all that dramatically over the years; if anything it's gotten smaller.
Yes, if you look at power at equivalent performance that looks better for apple, but then that's always the case because nobody runs client side CPUs at an optimal perf/watt power, but faster. It's also not really how people use their phones, is it? People don't turn off the high-power cores in iphones; they use em as designed, i.e. at approximately equivalent power, just faster.
The point here isn't that Apple's win doesn't exist; simply that it's not the mythological night-day difference it's sometimes painted to be. Furthermore, because apple consistently releases earlier on a new process node, at the moment of their release the perf numbers look better than they are on average over the products lifetime; in effect, you're seeing the combination of both Apple's good CPUs, and a 1 generation gap. Then there's the fact that Apple's CPU's are so fast due not solely to the skill of their silicon division, but also their willingness to spend for more transistors. We don't have numbers for the 888 yet, but it's very likely going to be a lower-cost design if history is any guide (and the anandtech article goes into some other non-obvious ways in which is saves costs too, like power planes, that I bet apple is willing to go the extra mile on).
All that matters, because you're trying to predict how other CPUs will perform, and thus need to tease out the impact of stuff like process node, and apples willingness to spend extra on larger caches, and x86 vs ARM - and just ascribing all that perf uplift to apples magic pixie dust won't help you make predictions regarding the rest of the CPU market in the future.
The 888 uses the same Cortex-A55 cores mentioned above (the same core all the Android SOCs have been using for a couple of years now) with Apple having a 4x performance win at the same power levels.
In any case, I think it's tricky to read to much into microbenchmarks like this; the overal system perf in any case does not have anything near like that perf difference, but instead a slowly shrinking gap (as described before, and supported by links to evidence).
I'm still curious about those efficiency cores mind you, even if I don't think it has much impact on the overall point. Also, one of the things qualcomm intentionally skimps on is powerplanes, I'm assuming for cost reasons - and that means low-perf power will be suboptimal. Then again, I'm not sure how much that matters.
(Don't forget the context of the Altera ARM server CPU and what it means for intel/AMD; efficiency cores probably don't tell a very meaningful story of qualcomm vs. apple, but certainly don't apply in that space, yet).
SPEC is not a microbenchmark. It's been the industry standard for comparing completely dissimilar CPU architectures for decades.
In any case, the link you shared (https://www.anandtech.com/show/16192/the-iphone-12-review/2) backs up what I said; the overall SoC perf of the 865 is quite close to that of the A13 (which is it's same-gen competitor). The specfp score of the 865 is 74% of the A13; the specint 64% (the 865+ is 3 percentage points better here). And the joules consumed by the A13 is significantly higher than the 865 for both benchmarks (the 865+ uses more energy than the 865, but less than the A13).
In fact, the geomean of perf and power between A13 thunder and lightning cores is pretty close to on the money for the 865, for both power and perf!
All in all, the 865 looks pretty competitive in the benchmark you linked; pretty much smack between the high-power and low-power cores of the A13: more efficient than it's high-power cores, but slow, and faster than the A13's low-power cores, but less efficient. Unfortunately, the page doesn't include the 865's low-power cores in the benchmarks, but from the point of view of disproving the apple-domination story it doesn't really matter: clearly competitors can build cores that are close to the cutting edge of apples power/perf tradeoff; they just choose slower, more efficient designs.
Where are you getting a 4x improvement in performance?
From the link you just quoted.
Here it is again:
>Look at the difference between Apple's "little" cores and the stock ARM "little" core.
>The performance showcased here roughly matches a 2.2GHz Cortex-A76 which is essentially 4x faster than the performance of any other mobile SoC today which relies on Cortex-A55 cores, all while using roughly the same amount of system power and having 3x the power efficiency.
So even if the low power cores in the A14 are impressive; clearly other competitors are capable of getting results that are competitive with apple on the same node - at least for the high power cores.
I strongly suspect the low power cores just aren't a priority for qualcomm; but in any case when in comes to servers (what this all started with), clearly the high-power cores are the ones that matter, and it's equally clearly not the case that apple's lead looks unassailable. It's been shrinking year by year, not growing, and the difference isn't as large as it's made out to be.
Looking at this data I get the impression that Apple has more resources to throw at the problem, and that some parts of their solution are simply better - but the difference is quite small, and they use more transistors to get there, and need more power planes (thus cost) to get the greater efficiency. The big difference is simply how much head start they get at TSMC, which is a question of money, not some secret design sauce.
And again this all started on a thread about server CPUs and memories of how slow chromebooks were (i.e. not talking of efficiency cores in isolation, but SoC perf overall). And for that I think data speaks for itself: Apple has a significant lead - but a small one, that's been shrinking over the years. There is no evidence they're in a class of their own at the same process node - other chips are 3/4 as fast and more efficient, and that seems like a reasonable tradeoff. Nor incidentally is this just a 2 horse race; much as samsungs chips are derided, they're not that much worse, and likely much of that is due to the inferior process node. Huawei too seemed competitive pre-trade-war, sometimes beating qualcomm. Given that at the same process node there are 3 different competitor that come so close, it just does look like Apple's design is really all that unique. It's quite conceivable a different ARM competitor might catch up in a few years, given the current trends. Then again - only if they get a slot at TSMC, since there are rumors that Apple has already bought much of the 3nm production, and as intel showed in the past - decent design with a process node advantage is a winning combination. But Apple needs that process node advantage to keep a large lead.
If you look a few years ago, a similar comparison would be the snapdragon 820 vs. Apples A9 (both on samsung's 14nm process, though apple was dual sourcing with TSMC 16nm). Then, the iphone 6s plus scored 535, and the oneplus 3 (using the 820) scores 306 - i.e. 57% of apples performance. On multicore it achieved 77% of the performance (also a larger difference than today).
Qualcomm has been catching up lately on single-thread and multithread perf, just not very quickly (i mean at this rate it'll be well over a decade before they're equal in single thread perf...).
Sources: https://browser.geekbench.com/android-benchmarks and https://browser.geekbench.com/ios-benchmarks, search for oneplus 3 and iphone 6s plus.
That's the difference.
Zen 3 EPYC releasing Q1 is likely to be a different story.
Sure, add a line for ARM.
What's interesting to me, I feel like a lot of this started when intel wouldn't do the chip for the iphone. All of a sudden you had this leading edge mfg pushing arm hard which drove volumes through the roof, and all the copycats (android etc) copied the chip selection, screen style etc as well.
I wonder how different the path might have been if intel had come up with something for apple.
- Arm has dominated low power / mobile segment from well before the iPhone due to its superior power consumption;
- The non Arm IP (eg Imagination GPU) was also important and it was unlikely that Intel would have been integrated that on their SoCs.
I had an Atom tablet from the time when Intel supposedly had competitive mobile SoCs and it really wasn't a great device - ran hot and very short battery life.
In all honesty the implementation and OS also matter. Most Atom tablets weren't particularly great (or even good) devices overall. And running Windows on a contemporary ARM SoC wouldn't have resulted in a better experience.
Apple tends to emphasize memory bandwidth in its own designs.
Apple came on the scene later, when Acorn had developed the ARM processor. You're right that they were an original investor in the spinout company.
They kind of tried and failed. Intel is completely stuck in their "x86 is the only way" culture. x86 just can't compete in the low power space. For phones, the x86 power requirements made it effectively DOA.
Sure, Atom could have competed with arm in some markets (small laptops for example, they had some success in the early netbook days), but Intel managed to screw even that up by deprioritizing Atom development - they thought they could make more money in the server space. Short term, not a bad bet, but it wouldn't surprise me if it set Intel's eventual demise in motion. We're starting to see the signs now.
They've been shooting themselves in the foot toe by toe for a while.
I hope they come back for a while though, I mean at least to like $55/share for undisclosed personal reasons.
When you do this type of deal, you get to work with top class engineers and real major customer driving your power / efficiency story.Intel at the time had the process node advantage as well.
What's happened is Apple has SIGNIFICANTLY funded massive capital investment in the ARM ecosystem and in non-intel fab because now those non-intel providers are critical. Imagine all that money flowing to intel just on fab side.
Rumors around TSMC and Apple for iphones is that Apple funds some of the capacity at TSMC and pays for leading nodes. I'm not sure of the scale of Apple's orders, but they are going to be meaningful both in quantity and what apple is willing to pay.
[1] https://www.techspot.com/news/87851-amd-rumored-working-arm-....
Of course, it's probably a mix, but I don't know if ARM alone has much in that mix. It does seem to me that, even if ARM held no performance benefit over x86, Apple would still decide to use it based on their use of it in their hugely successful mobile products.
>The one explanation and theory I have is that Apple might have finally pulled back on their excessive peak power draw at the maximum performance states of the CPUs and GPUs, and thus peak performance wouldn’t have seen such a large jump this generation, but favour more sustainable thermal figures.
Apple’s A12 and A13 chips were large performance upgrades both on the side of the CPU and GPU, however one criticism I had made of the company’s designs is that they both increased the power draw beyond what was usually sustainable in a mobile thermal envelope. This meant that while the designs had amazing peak performance figures, the chips were unable to sustain them for prolonged periods beyond 2-3 minutes. Keeping that in mind, the devices throttled to performance levels that were still ahead of the competition, leaving Apple in a leadership position in terms of efficiency.
https://www.anandtech.com/show/16088/apple-announces-5nm-a14...
This is a really tough strategy decision. Focus all energy on delivering a knock-out blow to Intel (in x86/64) or try to do other stuff too?
For the next several years at least, there is still a whole lot of money to be made selling x86/64 chips. (I don't know if Microsoft has plans to move mainstream Windows users off x86/64, but even if they do, it won't happen quickly.)
Right now, AMD has an opportunity to take x86/64 away from Intel. Probably the best opportunity in decades. There's something to be said for focusing all resources on delivering a knock-out blow right now, before the opportunity is gone.
On the other hand, ARM might have a better future over the long term. And it isn't necessarily true that AMD would be spreading itself too thin by trying to do both.
Yeah ARM isn’t x86. Apple made big gains by leveraging the difference in instruction length and complexity between x86 and ARM.
Something AMD can’t do, and they’ve said as much.
The only thing the M1 has integrated that a typical AMD or Intel laptop CPU doesn't have is a neural net processor. Everything else about the M1's 'integrated architecture' is typical.
Notably the M1's RAM is not integrated as is often incorrectly stated. It's just regular soldered LPDDR4X. And M1's RAM latencies are worse than Intel & AMD's socketed DDR4 latencies, so being soldered and physically close is definitely not providing a performance advantage.
ARM instructions are fixed length so it's very easy to stack up decoders next to each other. You don't need complex logic to figure out where instruction boundaries are, which you do with x86.
This added to a super long instruction pipeline means that the M1 has the ability to reorder a significant (something silly like 2x longer than any AMD or Intel CPU) number of instructions to increase CPU utilisation and thus performance.
AMD can't do this on an x86 CPU because the complexity involved is too high, and think someone has found comments from them basically saying so.
Yeah Apple did make gains from a better integrated package, some of that would be tricky to pull off else where without additional software support. Some of the other integrations would be tricky to pull of because it would reduce the amount of customisation OEM could do. Remember one of the big things Apple integrated was RAM, and making it unified memory for all the co-processors. That could be tricky to do, unless we move into a world where RAM is always integrated into CPUs.
I would love to be a fly on the wall on the corresponding AMD strategy meetings :)
I think to not focus on x86 right now would be a tremendous blunder on AMD’s part. And at the same time ignoring ARM for too long will give others (like Nvidia) time to setup shop and capture the market.
I wonder how much of the Zen architectural “backend” is amenable to be reused with a different ISA (I don’t even know if such thing would be possible). Perhaps they could have a very low-effort initiative to try something along those lines.
- It's in both AMD and Intel's interests for x86 to remain dominant for as long as possible. If they could it would be in their interest to drive Arm new entrants out of the market (I don't believe that will happen though).
- Introducing an Arm product (or even hinting at one) would add credibility to new entrants and undermine existing products.
- They could almost certainly switch to an Arm design reasonably quickly if they needed to.
There is also some uncertainty about the impact that Nvidia will have on Arm when it takes it over. x86 is AMD's jointly owned ISA - they have no control over the Arm ISA.
ARM's brand new 80-core system struggles to match AMD's year old 64-core system, while also being entirely unable to run some of the workloads either at all or in the 2S configuration. And with mostly comparable power draw and a much worse turbo story that ARM is trying to pretend is somehow a good thing.
Competition is great, but it's a bit premature to claim "the writing is on the wall" is it not? AMD has historically made ARM CPUs in the past, they're not rigidly stuck to x86 like Intel is, but it's also not like x86 is in immediate danger, either.
And per the article it sounds like it's ARM's fault this can't exceed 3.3 ghz. That seems to be a Neoverse-N1 limitation:
"Fundamentally, the Altra’s handling of frequency and power in such a manner is simply a by-product of the Neoverse-N1 cores not being able to clock in higher than 3.3GHz"
This messed up their whole CPU development pipeline, because their designs are tightly bound to the process node, and it's a multi-year process. Because 10 nm hasn't ever worked in volume, and their new CPU designs are based around 10 nm, their latest server chips are still based on optimized Skylake microarchitecture, which was first released in 2015.
Early indications are that Intel's next process node (which they're calling 7nm) is also experiencing problems, if those problems aren't resolved, that probably means they'll have cpu designs for 7nm that they also can't ship in volume, in addition to the 10nm designs.
If they can figure out their fab issues, and they don't have a corporate implosion, I'm guessing they'll start making competitive CPUs again; they've been way behind before and come back (anti-competitive practices helped make sure they had the finances for that, of course).
And Charlie is a bit of a polarizing figure. He's gotten some things hilariously wrong, but he's also been dead on the money for a lot of issues, and his documentation of what's happening / happened at Intel is pretty much crystal clear.
You could probably browse through all the 10nm articles there and get a good idea of what happened without purchasing a subscription, if you have a decent knowledge of the semiconductor industry.
EDIT: If you read though these articles, even the parts that are available to non-registered users, a pretty clear picture starts to emerge - https://www.semiaccurate.com/tag/10nm/
For some workloads, special things like AES-NI or other optimizations which only Intel (or another vendor) have can make a huge difference in real world performance which generalized benchmarks don't cover.
AMD in Zen1 had 2x AES-pipelines, allowing 2x 128-bit AES operations per clocktick.
Intel caught up later, and eventually also added 2x AES-pipelines of their own. But then AMD added 256-bit AES instructions to Zen3 (which are 128-bit x2 vectorized).
AVX512 does have 4x SIMD AES on AVX512 (4x128 bit wide), for 4x parallel AES computations per clock tick. But that's not on consumer chips. I guess that's the widest AES implementation right now however, but AMD isn't that far behind in Zen3.
--------
If anything, I'd say AMD actually was beating Intel at the AES-benchmark at Zen1 (In year ~2017 or so), but Intel / AMD have been trading blows with each other since then.
From benchmarks listed here: https://calomel.org/aesni_ssl_performance.html it seems that Intel had similar performance in their 2015 release of the i7-6700 as AMD's 2017 release of Ryzen 7 1800X.
Raw general purpose benchmarks I found via Google put the Ryzen 7 1800X at about twice the compute capability as an i7-6700, but their AES performance is quite even.
GCM mode can be parallelized. Notice AES-128-GCM (which can take advantage of 2x pipelines) really flies on Zen1 compared to 6700.
Thanks for your comments! I didn't previously fully comprehend how the AVX modes and pipeline widths mattered for AES.
You don't come up with 32-bytes of random numbers every 4-clock ticks unless you understand this stuff. :-)
That is of course in the context of Server CPU design. Your mileage will vary depending your usage.
With the announcement from Marvell's exit [1] of ARM Server CPU it is now all but confirmed that Microsoft and Google are also working on their own ARM Server CPU. Which means all HyperScaler will now have a common interest to have Software running on ARM. And this will trickle down to every part of the industry.
It will take some time, depending on your scale, the cost benefits of switching over may be different. But there is no denying that Intel doesn't have a short term ( 2-3 years ) answer. And I dont see their medium term ( 4 - 5 years ) are any better. Their new Optane SSD is really exciting though [2].
And I am willing to bet all of these New Server CPU comers has absolutely zero experience in CPU forecasting, and risk averse enough to put down commitment on capacity, which ultimately leads to TSMC getting a bad name yet again for "Not Enough Capacity".
[1] https://www.servethehome.com/impact-of-marvell-thunderx3-gen...
[2] https://www.servethehome.com/new-intel-optane-p5800x-100-dwp...
When AMD would switch to RISC they could also create a huge out of order capable cpu but would be lacking the co processors plus the tight integration and if they could add them they would lack the capability to drive and dictate that the cpu would be used in the most performant way.
So it seems to me that Apple is perfectly aligned to take a large part of the market and AMD as a general purpose cpu designer will need to come with a very competitive cpu either on x86 (ZenX) or on RISC to stay competitive. They can outsource the fabrication the chips. Intel meanwhile with its owned fabs has a lot more inertia and ego to turn around.
On the other hand, maybe AMD or Intel will find a way to increase the re-order buffer and the amount of “splicer” (I forgot the official name for the unit that takes the instruction code and translates it into chunks of microcode).
The M1 chip is undoubtably a remarkable piece of engineering. But it quite clear that Apple are never going to sell it standalone. It also seems extremely unlikely that Apple are going to get back into the server game again.
Apple sell high markup, low volume (relatively) products. Data centre severs are the opposite, and Apple have stated quite explicitly they’re not interested in building anything that isn’t a high margin, luxury, product.
In the consumer space, I can see Apple taking more market share. But again, the vast majority of PC are either business machines, or low margin consumer machines. Both markets that Apple doesn’t seem to be that interested in diving into (their enterprise support is crap, and see above regarding low margin goods for the consumer market).
In all I must disagree with this statement
> So it seems to me that Apple is perfectly aligned to take a large part of the market
Not because Apple doesn’t have the technical chops to do it. But because they just aren’t interested in that market.
As such I think AMD, and other ARM manufacturers have everything to play for, and no need to worry about Apple.
However, they do not have to sell the chip individually to be a competitor to AMD. If Apple’s are sufficiently attractive it will eat the market share of consumer devices from the likes of Dell/HP/etc. When they start selling less devices they have less need for AMD or Intel CPUs.
This leaves only the datacenter market where Apple will not compete with Intel and AMD.
Indeed, there is lots of room for a (new?) player to pull of the same trick as Apple for general purpose cpus. I just think they are not as well positioned because of the lack of vertical integration. So AMD and Intel indirectly have to worry about what Apple is doing.
Interconnect is key, e.g., see the improvements between zen2 and zen3, especially for the `4 < cores <= 8` models - which stem mostly from having 8 cores per die with direct good interconnect, instead of two dies with only 4 cores.
An anecdote: I got some hands on a box with a Cavium ThunderX2 96 logical core processor about two years ago, kernel compiled slower than on my high-end, but non overclocked and common, i7 based workstation from ~ 2015 - that is certainly not to a statistical relevant comparison and there may be some workloads that do good with those CPUs, but it's neither single thread nor massively parallel, maybe something in between...
It's (relatively) easy to have lots of cores on one die, it's not so easy to keep them fed.
In a shared-memory multiprocessor, all cores and all memory are logically connected along a massive shared bus, and both inter-core communication and regular core-to-main-memory communication takes up slots on the bus. In practice, of course, it isn't physically a single bus but a more complex topology (usually meshes, I think) with protocols that make it like a bus for cache coherency purposes.
One of the readily apparent consequences of interconnect is NUMA, non-uniform memory accesses. Historically (my information on this matter is a few years out of date, so I don't know how much this is true today), this has been a bigger issue for AMD than Intel, as AMD had wildly divergent memory latencies (2-3× between worst/best case) even for a 4-core processor. So if the OS decided to resume execution of a sleeping program on a different core, your performance might suddenly drop by ½ or ⅓.
For some benchmarks (such as classic SPEC, or make -j), multicore performance is approximated by running the same binary on every core and there is no sharing between different copies. The interconnect here matters only insomuch as the cross-chatter on the interconnect may impede performance. But HPC applications tend to be much more sensitive to the actual interconnect, since reading and writing from other processors' memory is more common (transferring halo data, or having global data structures that you need to read from and occasionally write).
The basic theory is called "MESI": Modified / Exclusive / Shared / Invalid. When a remote core reads a cache-line, if no one else has that cache-line then its the Exclusive owner. But if multiple caches have the cache-line, then it is a Shared cache line instead. If a remote cache changes, then your current cache-line becomes Invalid, while the cache line that's valid is placed into the Modified state (cache is correct, RAM is incorrect).
MESI isn't how things are done in practice: additional messages and states are piled on top in proprietary ways. But MESI will get you to the "basic textbook" concept at least.
EDIT: Oh, and "snooping". Caches "snoop" on each other's communications, which helps keep the MESI state up to date. Now you can have directory-based snooping (kind of a centralized push), or rings, or whatever. Those details are proprietary and change from chip to chip. In practice, these details are almost never published, so your best bet to understanding is "Something MESI-like is going on..."
May have consumed far less power doing the job though. For server farms performance-per-watt can be far more important than absolute speed per unit, especially for massively parallel tasks.
The connection fabric is utterly important, and expensive.
Early AMD Softiron and Applied Micro boards (which had 8 cores unlike the ThunderX which had 48 or 96) were actually faster, which I always found interesting.
But Ampere's previous generation (before N1) is fast, much faster than the ThunderX2. Afaik, they built it on top of previous Applied Micro IP. So I'd expect N1 to be in a different league and not worth comparing to ThunderX2.
I think you're getting ThunderX2 and ThunderX mixed up here.
I wouldn't say it's the same order of magnitude for the 2 comparisons, but it's definitely noticeable.
No one answered that and from the core to core ping-pong test the second processor their is some weird, possibly performance crushing issues.
I really hope something similar is going to show up for PC as well.
And then I'm sure most sheep-like OEMs will say "Oh, we want THAT, too. Where is it - we want it yesterday!" But AMD won't be able to provide one too soon, because they would've gone all in on Arm v8, and they'd want to squeeze at least a couple of generations out of that microarchitecture.
Something similar happened when Apple announced the first Armv8 processor and it took Qualcomm and all the rest 2 years to catch-up.
ARMv8 (i.e. 64-bit ARM), of course, has been around for a while now.
[1] Keep in mind that anything on Reddit not confirmed elsewhere is very likely either wild speculation or made up fiction.
I too have heard that they have their own ARM micro architecture project though
For a little while there was one partner who used it for Gluster ( or similar ) storage nodes.
It fit into the model of Arm processors that were performant enough to be the glue between hard disks or flash and a reasonably fast network. But after the PCI lanes were all dispatched there wasn't a lot of compute for applications on top.
We've also already seen that Microsoft considers ARM systems to be "special" enough to require locked bootloaders as well. Don't get me started on the mess in the smartphone world. I'd hate to see a world where the only "open" computing revolves around either Raspberry Pi-class SBCs or expensive datacenter servers, with no middle ground.
Meanwhile for arm64 Macs, they aren't either. Yesterday, https://twitter.com/xenokovah/status/1339914714055368704?s=2... was released to run unsigned kernels.
One can hope, I guess. If I could be sure I could run Linux without it being hobbled, and that Apple wouldn't pull the rug out from under me, I could actually see myself adding a Mac Mini to the stable.
Edit:
> Windows on arm64 systems aren't locked down.
Has this changed? I recall that on ARM, Microsoft requires that UEFI Secure Boot be enabled, cannot be disabled, and cannot load custom keys. So, you could boot Linux as long as it's been "blessed" by Microsoft, assuming they don't pull the rug out, much like the leaving Secure Boot enabled on an x86 PC (except on a PC you can usually load your own keys).
https://arstechnica.com/information-technology/2012/01/windo...
For 64-bit Arm Windows devices, they had the security policies of a conventional PC since the very beginning.
https://www.happyassassin.net/posts/2014/01/25/uefi-boot-how...
I find it funny that almost all the real gripes with user freedom infringement actually tend to come as a result of Microsoft or other big players getting their fingers into a hardware platform.
Now with Reunion merging both worlds, and Windows 10X only planned for 2021, it might be a different story.
There is a new announcement every half year or so by one firm or the other. But we've never managed to get beyond getting a sample, and not for a lack of trying. Numbers just aren't available, models change extremely fast, producers go bancrupt. Maybe it will get better as soon as one of the big server producers starts with Arms?
Edit: to clarify, I mean on AWS, not from the Amazon store.
Also, don't really like vendor lock-in.
I thought it would be horrible, but after a brief adjustment period it turned out to be okay-ish for my current work.
{ declare -p c=([action]=add [identifier]=0 [x]=0 [y]=0 [width]=80 [height]=80 [path]="mypic.png") ; sleep 5;} | ueberzug layer --parser bashData centers already do that. You could build your own rack and send it to them, but the more common model is renting preconfigured servers on a monthly or annual basis with them swapping out broken hardware as needed etc.
Cloud computing can save on administrative costs, but there is a huge world between building everything in house and AWS.
You can definitely save money this way but it rarely ends up being as much as touted - double digit percentages, not whole multiples - unless you’re really bandwidth intensive.
Heck, my 2015 MBP is still running Mojave (and thankfully still receiving software updates)
You're talking about the certificate revocation check that bypasses VPNs? That one is to prevent malware from being able to hijack and block certificate checks.
See this HN thread from ~2 months ago for an introduction: https://news.ycombinator.com/item?id=24838816
This is new behaviour to Big Sur, breaking existing tooling and providing a back door for Apple, and anyone who can exploit it like this guy https://twitter.com/patrickwardle/status/1327726496203476992
Until it does. Some future MacOS may need support of some new architecture feature, then it'll be "better buy an Arm13 mac if you want to run MacOS 2023!". Apple doesn't have a very good track record about supporting their own old hardware in new MacOS releases. Several iMacs and MacMinis come to mind. Their past behaviour sets a benchmark for their future behaviour, and since there are no reliable assurances about their support roadmap, I'd think carefully...
Apple's known for cutting compatibility when they have some goal that's served by it, or it's viewed as an albatross by their product side.
[1] https://everymac.com/systems/by_timeline/ultimate-mac-timeli...
[2] https://en.wikipedia.org/wiki/Mac_OS_X_Leopard#Release_histo...
Pine64 SOPINE Clusterboard https://www.pine64.org/clusterboard/
The troublesome piece is, of course, the horizontal scaling. For a cluster of ARM CPUs to be worthwhile, you need a job that can be parallelized, but not so massively parallel that it already runs on a GPU.
Even so, I think there's a lot of potential for these low end ARM devices. Ultimately, their impact on x86 could be the same as what x86 did to the previous generation of mini computers.
[0] https://www.solid-run.com/arm-servers-networking-platforms/h...
You can't compare it to owning a whole machine for several years, having bought it once.
$659 ryzen 5800X
$250 motherboard
To me, it says they have a system with 32 CPUs at 1.7 GHz for $800, and a whole range between $2,200 and $4,050.
> AMD’s EPYC 7742 which still comes in at $6950
A couple quick searches (Amazon, Newegg) show people selling the CPU-only for this price. Since that's the price they're comparing to the table, I think the table prices are for the ARM CPU only.
I think a high-performance ARM64 CPU from NVIDIA with an on-die GPU would be a great offering. In many benchmarks it's actually the on-die GPU that makes the M1 so much faster. A general purpose on-die GPU would help speed up a lot of low and mid-level cloud workloads, especially with native kernel support.
Good luck, NVIDIA. And godspeed!
> Each Neoverse N1 core with 1MB L2 is just 1.4mm^2, so 80 of them add up to 112mm^2. The die size is estimated at about 350mm^2, so tiny compared to the total ~1100mm^2 in EPYC 7742.
So performance/area is >3x that of EPYC. Now that is efficiency!
Such is the churn and iteration to challenge x86. I welcome it.
[1] - https://www.theregister.com/2020/04/21/scaleway_arm64_cloud_...
They could end up being a low end x86 vendor.
Rocket Lake is supposedly a "backport" of Sunny Cove to 14nm for desktop, coming Q1 2020.
Edit : I know Linux is customized to run on a variety of hardware, I was just pointing out that I never knew you could install Ubuntu on the mentioned hardware and have it take advantage of the available hardware, given that it has specialized hardware.
https://unix.stackexchange.com/questions/4507/how-many-cores...
That said, I agree with you that it isn't particularly surprising that Linux handles lots of cores fine, it's been run on more esoteric hardware for ages.
https://github.com/freebsd/freebsd/commit/d7704f9e75aafd312a... https://github.com/freebsd/freebsd/commit/5786fe85813a411327... https://github.com/freebsd/freebsd/commit/3ef92b2f0a0ff3f101... https://github.com/freebsd/freebsd/commit/1f181d2512f60098ed...
I understand TPUs and GPUs easily beat these guys but it would still be interesting to see what raw cpu power can achieve in 2020.
I have not done any machine learning on AWS Graviton2 CPUs but I ran many other CPU benchmarks on Graviton2 CPUs and overall I have been disappointed by their performance. They are still much slower than current x64 CPUs (x64 CPUs are up to 2x faster in single thread mode).
According to the benchmarks from Anandtech the Ampere Altra should have much better performance than Graviton2 CPUs as its performance is neck to neck with the fastest x64 CPUs.
so how much for 1u chassis, 512gb ram, 2 x 1tb nvme, 4 x 10gbe nic, dual psu? what can i run on this? proxmox? kubernetes?
or 4u chassis, 128gb ram, 2 x 128gb nvme, 4 x 10gbe nic, 100 x 16tb sata ? what can i run on this? centos? Ubuntu? zfs? gluster?
They've only got the 2U and no SATA, but that page prices up the rest of your specs.
You can run CentOS, Ubuntu, ZFS and Gluster.
Now the value of a private cloud is a subjective question, true, but personal experience suggests having it right there on home lan encourages practical use, especially in a shared flat.
The same setup with a more reasonably priced consumer proc (but no ECC) would be around 1.5k out front.
Things like "what's the best 32-bit number for my custom random number generator" ?? (Try all 4-billion+ 32-bit numbers and run statistics on them, then sort the results). Except not really, that kind of search takes less than 10 seconds now, lol. But that should give you an idea of the size / scale of modern CPU power.
Or searching for chess or other AI search tasks. Or deep learning. Or raytracing. Or LTSpice simulations. Or... you get the gist.