That's the question I have as well, but since microarchitecture is in large parts dictated by isa how custom it can really be?
On the other hand custom isa would require rolling the entire software stack, which is a complete non-starter.
Really weird article and announcement
CPU design isn't like software. A microarchitecture is some you design rather than adding features in a software-like manner, there is an enormous scope for design choices within a given ISA.
And using a custom uarch is also a statement to your customers, shareholders, competitors etc. that you mean business rather than just going the well-trodden path with ARM cores.
I'm not disagreeing with either of your paragraphs, they're both correct... but the thing to note is that, to some degree, they argue in opposite directions.
That's because a consequence of the second paragraph is that it's potentially business-profitable to make a "custom uarch" even if you make no use of the enormous scope for design changes.
The comment you replied to said "with a given ISA, how custom can the uarch be", implying that it would not be very custom.
You replied, in your first paragraph, that on the contrary, it could be pretty custom, with the implication being that it probably would be, because that's the value proposition that Ampere is presumably offering.
So your paragraph 1 is suggesting that the sentence "Ampere will now use a custom uarch" is an argument that Ampere's custom arch might well be pretty highly customized.
ON THE OTHER HAND....
Your second paragraph points out that simply being custom is a social signal (the signal of being, in your words, "that you mean business rather than just going the well-trodden path"). You argue (and I agree) that this social signal might make you more attractive to some customers. I.e. the signal might increase sales. This implies that it would be reasonable for Ampere to spend a certain amount on a barely-custom custom uarch, purely for sales/marketting reasons, as long as it didn't substantially harm performance. You know, because of the implication.
So your paragraph 2 is suggesting that the sentence "Ampere will now use a custom uarch" is NOT an argument that Ampere's custom arch has any particular need to be highly customized.
>but since microarchitecture is in large parts dictated by ISA
Well, Apple uses the ARM ISA for their A and M series chips, and but not ARM's microarchitecture, and their chips have significantly higher IPC than comparable parts from Qualcomm or Samsung. Similarly, Intel and AMD both implement the same x86 ISA, but the performance advantage has swung repeatedly between the two. Microarchitecture might be "in large parts" dictated by the ISA, but there's still enough left over for hardware designers to have a significant influence on the overall performance.
"microarchitecture is in large parts dictated by isa "
This is very much not the case. Just consider that, for example, Intel still supports running the same ISA that ran on 8086. The microarchitecture now running those instructions isn't at all like the 8086 microarchitecture. (Its running a bunch of other instructions too, but the points stands)
An example in the reverse direction, is that a some MIPS chip teams saw that MIPS was dying, and reused their MIPS microarchitectural designs to build ARM processors.
Sure, ISA can be designed assuming some things about microarchitecture, and then it can be inconvenient to change it. But not impossible. And during the transition to ARM64, ARM took the opportunity to remove things that were inconvenient for different microarchitectures (eg, directly accessible PC reg, changes to how condition codes work, etc)
Maybe risc-v will take current place of arm with arm taking over x86's segment of the market?
Risc-v being open would be a real boon for low cost embedded chips
The only companies I can think of that could really make it would probably be Apple (because they have an iron grip over that platform) or Intel (because they actually have good software unlike almost all of their competitors, which could make the migration easier) - Apple are happy with ARM and Intel are probably terrified after what happened with Itanium. Any move to RISC-V will probably either happen in China or incrementally.
I once read on HN that Apple gets ARM ISA and designs for free by virtue of being a founder. So the closed proprietary nature isn't enough for them to move to RISC V.
They probably have a very generous, very old contract by virtue of being the first third-party to use ARM in a device. But we won't know the specifics unless there's a court case that touches that relationship.
With the way Apple operates, we have ten years before we can reasonably assume that they would change their architecture. Is RISC-V really going to be worth all the headaches of a transition in ten years?
As previous posters have pointed out, Apple is not a third party.
"The company was founded in November 1990 as Advanced RISC Machines Ltd and structured as a joint venture between Acorn Computers, Apple Computer (now Apple Inc.) and VLSI Technology."
"Finally at the top of the pyramid is an ARM architecture license. Marvell, Apple and Qualcomm are some examples of the 15 companies that have this license."
Why is it that treating collective nouns (e.g. Apple) as plural has a tendency to trigger an irrational negative emotional response for me? What's even weirder is that I used to think that made more sense and used it too, until convention in American society changed my thinking to flip to singular.
The English-language grammar concerning pronouns and subject-verb agreement is something that shows a lot of regional variation. In the variety I grew up speaking, whether you use the singular or plural depends on both the part of speech of the word you're inflecting, and the specific collective noun you're trying to agree with. It's a complicated enough set of conventions that I wouldn't necessarily expect anyone who didn't grow up in the same region as me to be able to follow them precisely.
Long story short, it's probably not terribly utilitarian to have strong opinions about the subject when participating in an international forum such as this one.
RISC-V is first and foremost an instruction set architecture. Like all architectures it has a few weaknesses. But if you spend enough money, there is no reason for RISC-V not to be a competitor in the high-end performance segment.
Sure, you can make anything fast, but the question is will it take 40 years of a lot of work, and if so, where will x86 and ARM be when you get there?
I'd suspect an ISA designed in the last few years with performance in mind (even if not a priority), wouldn't take as long to get to where the industry is now, but it's still a lot of years of focused effort required, and we'll see.
I don't have a horse in the race, except that I do like my experience to not evaporate; and I sincerly hope real mode segmented address edge cases aren't something I'd need to relearn on another ISA even though they're still (barely) relevant on x86 in early boot.
The point is that you can make it fast more easily. Decoding x86 instructions in parallel efficiently is taxing, whereas with ARM and RISC-V it's much more tractable for example.
Saying X86 is 40 years work is also kind of stupid, as a huge amount of the ISA dead weight, and high performance implementations have their roots much earlier than that (e.g. Intel have tried to move on at least once and ended up coming back to the OOO superscalar paradigm).
Something I don't understand here: do we really have to pay ARM for their instruction set? Does AMD pays Intel a fee for using x86? Does Intel pay AMD a fee for using their 64 bit extensions? Does anybody pay the inventor of the SSE and AVX instruction sets? Does anybody pays Nintendo for deploying emulators?
The ISA is an interface, and as such may not be copyrightable or even patentable. Even if it was, we've had various interoperability exceptions, and one does need an ARM ISA to run a program compiled for ARM.
Besides, as far as I know ARM doesn't just license the ISA. It licenses cores. There's a good chance that if you make your own cores to implement an ARM ISA, you wouldn't have to pay any fee. You may however have to get around trademark, and not call your CPUs "ARM CPUs". Though I suspect "ARM compatible" would work perfectly (just like "IBM compatible" worked with third party PC vendors).
I believe the situation is that they both have relevant patents, especially since AMD went 64 bit, and so they cross-license to each other and call it even.
Even if you don't have to legally, you want to because those license fees are how the money for the next ISA version are made. It is a prisoners delimma situation where nobody has defected.
The terms are secret, but basically yes, AMD had access to 386? designs and what not as part of IBMs second source requirements with Intel, but Amd486 and up designs were AMD original with instruction sets under license from Intel, although the licenses were set up after release under litigation.
> Does Intel pay AMD a fee for using their 64 bit extensions?
Yes / sort of. Use of the AMD64 extentions was negotiated under the broad cross licensing between the two companies.
> Does anybody pay the inventor of the SSE and AVX instruction sets?
Do the persons involved get royalties? I'd guess not, but who knows. Would you have to pay more to get a license for them, almost certainly.
You'll note there's been a lot fewer x86 processor designs not from the big two over the past many years than there were in the late 90s. Some of that is because 'RISC is going to change everything', but a lot of it is becsause nobody can get an x86 license.
> Does anybody pays Nintendo for deploying emulators?
I don't think so. Patents are too old, and there's not a whole lot of non-Nintendo emulation in the commercial market (but I know Capcom has released some collections, of Megaman games, etc). If those types of releases started including systems with system roms, then you would start having copyright claims.
Nintendo has never seriously impeded system emulation; there's just no case to be made. ROM distribution is clear copyright violation though, of course.
I don't agree with that. The base ISA is highly optimised for high performance. Many of the decisions made are precisely because it makes it easier to design very wide superscalar CPUs. The vector extension is also looking like it'll be more efficient than ARMs.
What's missing, is instruction set extensions that makes it comparable to ARM/x86 across all workloads. And obviously it's far less mature in general.
Sorry, RISC-V is not a bad ISA, but saying that it "is highly optimised for high performance" is extremely far from the truth.
RISC-V has been optimized for a single-purpose, being as simple as possible to be easily taught to students and implemented by them in a limited time.
It lacks many features required for high performance without hardware of excessive complexity, the most obvious being that RISC-V does not have decent addressing modes, so that the highest performance implementation reported until now (by Alibaba at the 2020 Hot Chips Conference) had to add a non-standard ISA extension to correct this.
Nobody remotely competent chooses RISC-V for "high performance" in any definition of that term.
RISC-V can be the right choice in many cases because:
1. No costs for using the RISC-V ISA
2. Easy customization with non-standard extensions
3. An already existing complete software development environment, with compilers, debuggers etc.
4. Acceptable performance at a given implementation cost
There is no need to invent extra fictitious advantages, like "high performance".
In other words, it's basically closer to a replacement for MIPS, which is already everywhere in a lot of embedded devices (and arguably not "high performance" ones --- the cheapest tablets and smartphones use MIPS.)
It is actually a replacement for MIPS in a more literal sense: The company owning MIPS has recently renamed itself to MIPS, and it abandoned MIPS ISA in favor of RISC-V ISA.
> It lacks many features required for high performance without hardware of excessive complexity, the most obvious being that RISC-V does not have decent addressing modes, so that the highest performance implementation reported until now (by Alibaba at the 2020 Hot Chips Conference) had to add a non-standard ISA extension to correct this.
Do you have any proof that additional addressing modes would increase performance? What I remember from college and papers I've read is that more modes are generally a detriment to pipelining.
Maybe you're talking about "needing more instructions". You'd be wrong in this case. Using the compact instruction set gives an average of 15% more dense code compared to x86 and somewhere around 25-35% more dense compared to aarch64 (about equivalent density to thumb, but without the switching overhead that makes thumb slow).
"Xuantie-910: A Commercial Multi-Core 12-Stage Pipeline Out-of-Order 64-bit High Performance RISC-V Processor with Vector Extension"
From "VIII. NON-STANDARD INSTRUCTION SET EXTENSION"
Targeting at various industrial applications, XT-910 enables
a set of custom non-standard instructions, additional to the
standard RISC-V instructions. The non-standard instruction
extension can be categorized into two groups based on the
purposes - memory access enhancement, and basic arithmetic
operation enhancement.
A. Memory access enhancement
Memory access instructions usually account for a high
proportion in the total number of instructions, so enhancing
memory access instructions can directly benefit the overall
performance. By analyzing the mainstream applications running
on RISC-V, we observed that for the basic RISC-V instructions
there is still quite some room for improvement in memory
access related instructions.
First, we support register + register addressing mode, and
support indexed load and store instructions. This type of
instruction extension reduces the usage of the registers for
calculation and reduces the number of instructions for address
generation, thereby effectively accelerating the data access
of a loop body. Second, unsigned extension during address
generation is supported. Otherwise, the basic instruction set
does not support direct unsigned extension from 32-bit data
to 64-bit data, resulting in too many shift instructions.
I'm not certain if they break out the results by individual optimization, but in Fig. 20 in the paper it looks like all their tweaks add up to a 20% boost over the standard RISC-V ISA. Pretty huge.
>in Fig. 20 in the paper it looks like all their tweaks add up to a 20% boost over the standard RISC-V ISA. Pretty huge.
>I'm not certain if they break out the results by individual optimization
They don't, so it's not clear where the 20% comes from. They're using a compiler that optimizes for their microarchitecture, which might account for a lot of that. As for the mention of "extensions", it's not even clear to me whether they mean official RISC-V extensions such as IMAFD or custom extensions.
That's simply wrong. RISC-V is explicitly designed to enable high-end performance. That was literally one of their goals. Of course with the necessary extensions but that is the case on all ISA.
This is a load of bull, and it can be readily dismissed after reading the first pace of the unprivileged spec[0].
As a practical counterexample to that FUD, it is also the ISA chosen by the Barcelona Super-computing Center EuroHPC[1] to design a new high performance CPU for future supercomputers.
Could a chip have two ISAs? If instruction decoding is as minimal as Intel makes it out to be, then it should be able to have two ISAs translating to the same microarchitecture, non?
The ISA affects more than just the instruction decoder. For instance, x86 has partial register writes and TSO memory ordering; RISC-V does not have a condition code register, and has some special rules for the division operation; and so on.
However, RISC-V is so minimal that it might be possible to add it as a second ISA to a chip without much effort. On the other hand, it's so minimal that a JIT translator from RISC-V to the native ISA can be a valid alternative (see for instance https://carrv.github.io/2017/papers/clark-rv8-carrv2017.pdf).
Definitely. Some ARM processors can switch between ARM and Thumb mode for example, and I think I've seen it on different types as well, but not 100% on details; IIRC things like chips that were compatible with 6502 or similar, but had a native mode with more capabilities and a different instruction set.
Of course, it helps if the ISAs are at least broadly similar in terms of register space and available operations and memory ordering specifications. And the performance is in the details.
Geopolitics has ensured that RISC-V will be relevant for the foreseeable future. China, Russia, Iran ... and any other country that doesn't want to be locked out of computing by an American embargo, are doubling down on RISCV development. In Russia's case its mostly military hardware applications. In Iran's case its just software. But in China's case its heavily funding projects to bring commercial products to market to replace US-controlled IP on everything from mobile phones to desktop workstations. It will take ten years for these projects to see fruition, but the Chinese state is pouring state-actor level funds into the project through multiple different private and public entities.
It's good news for open source hardware development. But bad news for USA and for people with security concerns. I don't know how comfortable I'd be with a Chinese designed CPU, Chinese compilers, and a Chinese kernel ... even if they were all open source.
How comfortable do you think the rest of us are with US-designed CPUs and software? I’ll take the country that hasn’t invaded and is still occupying much of the world, I think.
It's a personal choice ... but if you study Chinese politics I think you'll find their lack of aggression isn't an orientation, its a historical lack of capability ... which is now changing.
The US Empire is corrupt, but its processes of decision making and power are relatively transparent (open elections, senate trials, etc.). The Chinese system is entirely opaque. In a sense, all citizens in China are ultimately completely vulnerable to the whims of the state ... there is no recourse for arbitrary detention, seizure of property, etc. This is a model China seeks to export in the long run ... either directly, or through affiliates.
America sucks ... but as people often say about Democracy, its the worst system of governance except all the rest.
The US isn’t democratic. Every human on earth is at the whims of US state power. There is no recourse for arbitrary detention (like Guantanamo or the border concentration camps), assassinations, invasions, coups, etc.
I’ve studied Chinese politics and have reached the opposite conclusion to you.
I suppose we'll have to disagree, considering that you even know about Guantanomo through US court documents is a reason to doubt your line of thinking.
Guantanamo was not public for a long time and any legal proceedings were famously impeded. We didn’t even find out about the torture for a long time. The film The Mauritian portraits this quite well.
Abu Ghraib wasn’t made public through courts at all.
How many other such places exist and still kept secret for now? The past would suggest there are at least several.
America's internal process revealed these things. Its own journalists and its own whistleblower mechanisms.
If you lived in America, you would see the huge amount of protests on the streets against the Iraq war and other international adventures. Also, US politicians with significant power regularly speak out against such adventures.
This is America's internal control mechanisms. There are no such mechanisms in China.
Anyway, there's no point discussing this further. Either you understand this level of nuance, your you inherently believe in the notion that "all countries are equally bad" type philosophy with no regard to how information is brought to light and how a country is constrained.
All countries aren’t equally bad, the US is far worse than any other.
Guantanamo bay is still open, despite what happens there being illegal under Cuban, US and international law. Julian Assange and Chelsea Manning are still persecuted.
You either understand that your country is oppressing the entire world or you blindly believe everything your ruling class tells you.
RISC-V's play won't be in the desktop or server market but in the absolutely huge embedded devices market. A place where the licensing cost on an ARM core can actually contribute significantly to the BOM. Or where having the ability to roll ones own ISA extensions can have a significant win. Or where the politics of licensing a core from a corporation HQ'd in a geopolitical rival means something.
Something related to being able to go full speed without thermal throttling / instruction side effects? I.e. You know what the consistent performance ceiling is, and it won't drop just because you started using avx512 instructions on a nearby core?
Not having some instructions be a noisy neighbor is a good idea. But it seems wasteful to cap 128 cores at the power output possible if all cores have that output (if that's what it is).
Assuming the default mode of operation is having just a few cores operating at 100% with the majority running at 0%, it's wasteful to not let those active cores run as fast as possible.
Why would the default mode of operation for a 128-core datacenter chip be to have 120 idle cores?
Obviously the default mode of operation is to run all cores, or very nearly all cores, at full tilt all of the time. This chip is designed to be garbage at few-threaded workloads.
Indeed. For cloud vendors, a large part of the business model is to resell/oversell idle CPU time as much as they can ("vCPU"), taking advantage of the fact that small/individual clients are usually extremely over-provisioned CPU-wise.
That depends on the workload?
For HPC it’s easy, for other loads like DBs or VMs it’s harder, especially with fewer nodes (e.g a single node running 32 VMs with dedicated cores will probably look a lot like a desktop workload with lots of idle cores). I suppose it’s going to be rare to see these in deployments with fewer than several dozen sockets, and workloads must be balanced (so e.g not using dedicated VM cores).
That’s I suppose a simplification they can make by focusing only on “datacenter” while intel needs the same design to work from 1 socket to hundreds.
Depends what your use case is. HPC for example wants predictable performance with every pipeline filled as much as possible - there won't be idle cores. The average performance is more important than bursts there. That's one of the reasons hyperthreading is universally disabled in HPC clusters.
I realize it's probably targeted at hyperscale "cloud" stuff, but when their previous CPU was announced, I took a good long and hard look at what it would take to actually buy and use it. Unlike being able to buy a $650 Supermicro, MSI or Tyan dual socket motherboard and put your choice of a couple of Intel or AMD CPUs on it, it turned out that it was unavailable for mere mortals to purchase at any reasonable price.
My message for people trying to make "ARM Server" CPUs a thing is that you have a real chicken or egg problem to solve, getting these things into the hands of people doing Linux development on x86-64 right now. Without a robust ecosystem of all the Taiwan-based motherboard manufacturers behind you, it's never going to get more than a few percent market share.
This is exactly the same thing that happened several years prior to Ampere, with other "ARM Server" CPU vendor offerings. I thing it turned out that the only thing I could purchase was a $3000 cpu and motherboard kit that were significantly slower and weaker than a $350 core i7 on a $120 motherboard (at the time, this was at least 3.5 to 4 years ago).
I think you mistake marketshare with mindshare. The devs can play with Raspberry Pies or similar, because why not, it runs AARCH64, don't it? The few devs who really need deep system level access are either paid, or get devkits. Meanwhile, 'the market' IS the hyperscalers. Nobody cares about the few nerds wetting themselves. They can go gaming, obsess over retrocomputing, toolkits, theming, /r/unixporn, whatever.
I do think getting it in the hand of more people, more people will run it and say "yes, works" and then take it into consideration when making architecture/purchasing decisions.
I've been a CTO for a decade+ and did try to get one the last time they made a splash.
>Nobody cares about the few nerds wetting themselves. They can go gaming, obsess over retrocomputing, toolkits, theming, /r/unixporn, whatever.
The problem with this stance is that they can also keep using the non elitist platform, considering the elitist platform is inferior for many use cases.
Nerd mindshare eventually converts to some marketshare. Adobe has been lax on their enforcement of their software among non-professional market segments for this exact reason.
Years ago I read an interview with one of Intel's upper managers for the Itanium product line and when he listed off the various reasons it was not successful the top of the list was the lack of availability to those people actually doing the work of Linux & compiler development having very expensive and unplanned consequences.
I presume that the performance segment that Itanium was intended for is Intel's most profitable. So everyone who proposes to make server chips targets that segment, pretty much to the exclusion of everything else.
Having seen this play out a number of times I don't think targetting that segment and only that segment is a great idea.
From a stack perspective, you can't really go it alone anymore. The total necessary software universe is too large to rebuild on a reasonable timescale, and too expensive to rebuild by oneself.
IBM is about the smallest scale that can do this -- and even they're leveraging decades of effort.
I don't know if getting Itanium to more people would've saved the platform because of their architecture. The first models had trouble with their memory performance, which was fixed in hardware. The compiler also needed to watch the instructions it outputted, as not putting out the right combination of instructions in order would leave CPU hardware underutilized. Instructions were very wide, causing more frequent cache misses as the cache was full of instructions that were shorter in other architectures. Furthermore, the compiler needed to emit certain hints for the branch predictor and other speculative execution units to function well.
I think the lack of availability certainly didn't help, but the architecture itself was probably the biggest downfall of the IA-64 platform. When it was introduced, the hardware was certainly advanced, but relied too much on software to get proper performance out of the chips. The product was doomed from the start.
Ampere will likely have entirely different problems bringing their architecture into the market, but I don't think Itanium ever stood a chance even if they'd sent out free chips to as many influential people and companies as possible.
There were many reasons why it failed but I think the combination of these two was more synergistic than it seems. Itanium’s designers made some very dubious assumptions about the kind of code they needed to run (businesses buy branchy code, not hand-tuned SPEC benchmarks) but then the systems cost considerably more than the earlier predictions and almost everything was much slower than predicted because few developers had access to a system to tune it and the best compilers were not free.
The architecture was probably a fatal mistake on its own (even if Intel had disbanded its x86 line, the “older” RISC processors outperformed, often substantially) but ensuring that almost nobody saw anything close to what performance it could deliver definitely made it fatal. If Intel hadn’t been greedy trying to charge for compilers, the gap wouldn’t have been nearly as bad.
This must have been a huge part. Maybe ICC could squeeze more MIPS per dollar out of Itanium than x86, but if GCC can't, people are going to not buy Itanium rather than buy ICC.
It was especially hard because compatibility was not a given and proprietary compilers of that era were notorious for having both compatibility issues and fragile optimizations where seemingly minor code changes had large performance impacts, especially when they’d basically targeted one SPEC benchmark. I saw multiple times where teams switched to GCC for compatibility/features and the performance impact on most other platforms was relatively modest.
> The compiler also needed to watch the instructions it outputted, as not putting out the right combination of instructions in order would leave CPU hardware underutilized. Instructions were very wide, causing more frequent cache misses as the cache was full of instructions that were shorter in other architectures. Furthermore, the compiler needed to emit certain hints for the branch predictor and other speculative execution units to function well.
I think that's the kind of issue they're talking about. If it had been easier for nerds in bedrooms to run Itanium, we'd've seen much better support for it in GCC etc. much sooner.
I don't disagree with your comment but I think “nerds in bedrooms” is possibly what works for tuning a particular open source project. GCC and other popular open source projects should have been a room full of Intel engineers because it's a hard problem and their revenue from their proprietary compiler & libraries was a tiny rounding error of the amount they spent building Itanium.
Back when I supported computational scientists, the total cost of the servers + compilers was so steep that even if everything had worked as well as the Itanium salespeople promised it would have needed to be many times faster to be worth the hassle of changing toolchains, especially since you had to pay up front for the hope that with a fair amount of work you'd at least hit the point of breaking even.
Later Itanium chips literally went right back to the "hardware JIT" (speculation, OOO, etc) they were trying to get away from in order to increase performance.
If Itanic had won, we'd still be basically where we are today from a hardware perspective, but with even less competition.
‘Unplanned’ only because Intel learned absolutely nothing from the i860. Amazing performance on a hardware spec sheet, while real programs could never gain the benefit and only paid for the complexity.
In the end of the day it will be Apple disrupting x86 on servers. I already can run all my work related stuff natively on M1. There’s JDK, Node is here as well, ones lots of devs have M1 on their desktops it will only make sense to run aarch64 on servers as well.
> In the end of the day it will be Apple disrupting x86 on servers.
Apple made it happen on the client, but Amazon is making it happen on the server. The people who want to run their own DCs or hardware will end up part of the niche left on x86. I don't see Apple doing anything in the server space beyond providing minis like they do now.
Do you think a lazy troll is contributing to the conversation? You could look at Apple’s old XServe pricing to see how much markup they historically had, or compare the current MacPro to equivalent workstations — it won’t be 2 orders of magnitude, and based on what we’ve seen so far it’s more like to be within the range of +-25%.
I think what's interesting is that having access to a good development platform (the M1 mac) might enable projects like Docker, Node or Linux to get up to speed on ARM earlier. The dev experience is really much better on a local machine than working through SSH on a server.
From my standpoint there isn't much else to speed up. I'm already running a bunch of workloads on AWS Graviton2. Having an m1 Mac did help a bit with testing, even though the final is running on ARM Linux. Which btw, Linux already runs on ARM just fine from what I've seen.
I’m no expert in the area, there must be someone in Apple doing a profit analysis on selling server cpu even if the profit is tiny the economy of scale alone carries a benign
Whatever goes in the Mac Pro will likely be as capable as x86 data center chips at a fraction of the power requirement. Whether they put it in a server is another question
I’d expect Apple already has more than one proof-of-concept M1-based operational data centers.
If they are to be commercialized, I’d expect them to be part of a development stack related to Xcode, or some kind of AWS like services for applications developed for the Apple ecosystem.
Offering generalized compute would invite too much initial cost performance comparison and they couldn’t keep up with demand.
(I’m not sure whether that includes servers at large cloud providers, but I don’t think that matters. Unless there’s a huge performance advantage, I don’t see Amazon, Google or Microsoft buying Apple server CPUs)
I do admire how Apple did the M1 release. There was a lot of publicity with developers, good performance and solid roll-out with availability in everything, and it seems to be picking up steam. It seems obvious to everyone they are fully committed and that if you spend the time getting your software ready for it, then you will have a market. I'm not even interested in the Apple ecosystem and I am familiar with the major developments.
RISC-V International's plan to give away 1,000 boards to developers seems like a good idea. I like some of the products I've seen but the cheap ones are just toys and the decent ones are way overpriced.
Anecdotally, a guy in the Fedora project took a chance on giving a free OLPC laptop to a random education student in the middle of nowhere Utah. We met at a Panda Express in a strip mall. He helped me with some random problems I had on my ubuntu laptop and gave me a list of good resources to learn python.
I never did deliver for the OLPC project, but I tested a lot of things other people were working on. I also finally grokked the free software idea and became and engineer instead of a history teacher.
The $250 or so of prototype hardware has been repaid in testing, bug reporting other things I was able to do then. It sits on a shelf in my office to remind me how I got started, and what it mean to really be a part of a community that takes risks to invest in newcomers.
That's a very neat story. I have always loved the idea of paying things forward - investing in things or people in which you yourself do not see the direct return. Thanks for sharing.
Once Raspberry Pi CM4 support is added, I assume that you would be able to work on drivers for PCIe devices as well. Besides, non-server vendors like NXP have released official boards with ARM ServerReady support.
You can get ARM desktops now at non-crazy prices. The neat thing about them is they are 32/48 core CPUs at consumer-available prices[0]. Sure, they're on the high end, but it's around the cost of a workstation that one might use for, e.g., kernel development.
I'm not affiliated with Avantek in any way. I just did a bunch of research looking to build/buy a desktop, and ARM was a contender, but I ended up building a beefy x86 machine with a Ryzen instead.
I remember and interesting speech by Linus Torvalds about success of x86 and why is hard for AMD to break into servers that I think can be relevanto for Ampere too:
"I can pretty much guarantee that as long as everybody does cross-development, the platform won’t be all that stable. Or successful.
Some people think that “the cloud” means that the instruction set doesn’t matter. Develop at home, deploy in the cloud.
That’s bullshit. If you develop on x86, then you’re going to want to deploy on x86, because you’ll be able to run what you test “at home” (and by “at home” I don’t mean literally in your home, but in your work environment).
Which means that you’ll happily pay a bit more for x86 cloud hosting, simply because it matches what you can test on your own local setup, and the errors you get will translate better…
Which in turn means that cloud providers will end up making more money from their x86 side, which means that they’ll prioritize it, and any ARM offerings will be secondary and probably relegated to the mindless dregs (maybe front-end, maybe just static html, that kind of stuff).
Guys, do you really not understand why x86 took over the server market?
It wasn’t just all price. It was literally this “develop at home” issue. Thousands of small companies ended up having random small internal workloads where it was easy to just get a random whitebox PC and run some silly small thing on it yourself. Then as the workload expanded, it became a “real server”. And then once that thing expanded, suddenly it made a whole lot of sense to let somebody else manage the hardware and hosting, and the cloud took over. (All emphasis original)"
I'm not sure I agree. Many customers are working at a level of abstraction where this objection is not relevant.
For example, if I'm building on Firebase with Cloud Functions I'm so far abstracted from the underlying hardware that these architecture specific issues are less important.
Similarly, if I'm working in Django/Python on AWS RDS, using an ARM server for my EC2 instance might be an issue ... but moving my RDS Postgres instance onto ARM might not make a difference.
It's that way, and you're 100% right, until you hit the corner case performance bug that you can't track down and you spend hours trying to track down why some performance counter is incrementing monotonically on one platform but not on the other. Or why some highly threaded code has great throughput on your development workstation but falls down in production and it probably has something to do with differences in lock behaviour, etc.
That’s already true today. At work I have a 12 core laptop with 32gb of RAM. In the cloud is significantly more on all fronts. We encounter all the challenges you mention and still make it work (and yes, it’s hard). That being said, I doubt anyone writing in a managed language or hitting the database will actually care. Databases that have defects on a certain architecture will have resources poured into finding and fixing the issue (although it’s entirely possible there will be cloud lockin for those fixes if they aren’t contributed back)
This reminds me off that story on hackernews about getting that laptop in the datacenter, because they couldn't figure out why it was slower on the server.
> moving my RDS Postgres instance onto ARM might not make a difference
I have no specific knowledge here but I imagine the x86-64 builds are far better tested, regarding correctness. As cmrdporcupine points out, the performance of the x86-64 builds will also have been better studied. Whether it's an issue in practice, I don't know, but if you're looking to minimize risk, there are good reasons to stick with x86-64.
Most people are essentially developing fancy/overcomplicated wordpress themes. They're at an abstraction where architecture just isn't exposed to them directly, or as much.
I can certainly imagine a 'serverless' platform like Lambda or something where running on ARM is just an implementation detail (if it's not already).
That is true, but it is also true that the WordPress and PHP running on that ARM lambda will not be as stable as the x86 lambda if the vast majority of their developers only run x86 at home.
>It wasn’t just all price. It was literally this “develop at home” issue.
Whether you're right or not, I think I agree with the idea.
It also seems to me that, in general, working with a different CPU architecture and instruction set implies that the new & improved stuff has to be significantly better to be worth the cost and risk.
At this point, is one really that much better than another? Are large improvements happening at the margin?
Another camel that'll poke it's head in the tent, in large/expensive embedded (which I realize that the parts in the article aren't aimed at) is whether a CPU and it's battlegroup of other stuff will be supported right off the bat by software infrastructure and later on by actually being available in the long run. You have to wonder how out on a limb anyone who used a Motorola 88k felt.
If that were actually an important factor then no-one would do development on OSX, because servers don't run OSX, and the debugging, tools etc. are all a bit different on server *nix from what they are on OSX. And yet we see many developers who'd rather use a Macbook. So while there may be some premium to being able to "develop at home", clearly many developers value other considerations more highly.
That happened in 2006, and I would argue that the effect of them moving from PowerPC to Intel was dwarfed by the effect of people wanting to be able to do things like iPhone app development.
I think it was a bit of that, mixed with the iPhone launch and subsequent release of the App Store and third-party apps. Limiting app development and distribution exclusively to Macs through Xcode probably forced a lot of people into using them for the first time. Mac OS X also received UNIX certification around this time IIRC, I wouldn't be surprised if that compatibility pushed some more people tired of fiddling with their OS towards the "it just works" Mac.
Macbook-as-developer-machine started getting popular around the release of the iPhone. Apple took the opportunity to lock down their ecosystem and allow you to exclusively build and sign applications on their own platform, basically locking out anyone who isn't a Mac owner.
I'm not understanding what you're contrasting when you say they locked out people who didn't own Macs.
From 1984 to the iPhone, I believe it was the norm to develop Mac applications on Macs, except for a brief period when the very first models were starved for memory.
OSX is a different abstraction layer from processor architecture. Until recently Mac hardware was x86 and all the deployment targets were x86. A VM could take care of all the other differences.
> OSX is a different abstraction layer from processor architecture.
It is, but it introduces enough differences that you're not "at home"; indeed I'd say OSX-to-Linux is a bigger difference for development than x86-to-ARM.
Servers don't run Windows either, but Linux still is still the preferred server platform. Being UNIX-like is way more compatible than a different instruction set altogether.
Many people use macbooks as glorified terminals to run a text editor and a browser, while running the actual program being developed on a remote Linux machine.
Even more people use macbooks to develop for the browser, or to develop using platform-independent languages: Python, Ruby, Node, maybe even golang.
Quite a few people then package their backend code in a container and test it in a Linux VM which "Docker for Mac" helpfully provides.
But indeed the fact that Macs used to run on Intel, so the libraries you used in development were mostly that same versions of the same code as in production, must have been helping.
>If that were actually an important factor then no-one would do development on OSX
People only develop on MacOS because of how similar it is to Unix, not in spite of it. Go ahead, look at how many developers were using MacOS before OSX. I'll wait. The reason why people develop on Macs is because it's "close enough" to Linux to deploy with, and "good enough" as a desktop to keep tabs on most of your other apps.
> So while there may be some premium to being able to "develop at home", clearly many developers value other considerations more highly.
Let's clear this up: there is no development without development at home. If you work for a company as a developer, you'll be expected to maintain a machine that can consistently build and deploy your software. Unless you're working as a web developer (in which case, may god have mercy on your soul), you're probably going to end up using an x86 machine. Hell, my best friend is a die-hard Apple fan, and even he has admit that he can't really upgrade his Xeon iMac unless Apple offers him an upgrade within the x86 ecosystem.
>Unless you're working as a web developer (in which case, may god have mercy on your soul), you're probably going to end up using an x86 machine. Hell, my best friend is a die-hard Apple fan, and even he has admit that he can't really upgrade his Xeon iMac unless Apple offers him an upgrade within the x86 ecosystem.
He makes a living provisioning x86 servers, and maintaining legacy code is kinda his entire job. afaik, his main concern is that current Macs won't have enough memory (he's not upgrading to a machine with less than 64 gigs), and that he won't be able to natively debug or work on the same software that his clusters will be running.
> Go ahead, look at how many developers were using MacOS before OSX.
There were plenty of other problems with pre-OSX MacOS.
> The reason why people develop on Macs is because it's "close enough" to Linux to deploy with, and "good enough" as a desktop to keep tabs on most of your other apps.
The differences between x86 OSX and x86 Linux are bigger than the differences between x86 Linux and ARM Linux, in my experience. So these machines are also "close enough" to ARM servers.
> there is no development without development at home. If you work for a company as a developer, you'll be expected to maintain a machine that can consistently build and deploy your software.
Most developers have a local development environment and a separate production environment. Developers place some value on having them be similar, but they're also happy to introduce differences between local and prod for the sake of other tradeoffs.
Linus knows what he knows, but he has some significant blindspots. Here, it's the existence of languages other than C. I think this argument basically doesn't apply to any interpreted or JITted language.
I wouldn't be at all worried about deploying my Ruby, Python, or Java app on ARM, having worked with x86 locally.
That is, as long as the Ruby, Python, and Java development teams themselves have been able to test on ARM hardware themselves!
Definitely. A huge chunk of Python and Ruby packages are written as "C extensions", and if those C extensions are going to get compiled on some platform the developers haven't tested them on, it will make for fun surprise bugs.
I know Java has C extensions for some things too. I'm curious how much code is actually "pure Java", but I've actually rarely seen Java used at any of the places I worked at.
Kindasorta? Even higher level languages still rest atop the native code. For starters, someone's got to maintain the port of the interpreter or VM. It's going to get a lot more attention if developers are using it as their daily driver.
And then there are all the other native and system packages that you depend on. For example, I do a lot of work in Python, and I would be very hesitant to have anything but an Intel CPU in my workstation. Because that's what our servers run, and I know that a lot of packages I use include native code that has been carefully tuned for Intel CPUs. If I choose AMD or get an M1 Macbook, I'm going to have a much poorer sense of how the things I'm working on would behave in production.
That said, I'd be willing to at least try it. On the other hand, if work started talking about switching to ARM servers in production, I'd instantly be clamoring for a (non-M1) ARM workstation to develop on, because I need to know that I'm not going to get into trouble with packages that get a lot of love in the x86 versions of the native libraries but not so much on ARM.
> For starters, someone's got to maintain the port of the interpreter or VM
This was a good argument a couple of decades ago. Now? Keep in mind that most devices in this planet are ARM-based, ever since we started talking about 'smartphones'. They have been running these interpreters for a long time now. Most applications and libraries of any importance have been ported.
> If I choose AMD or get an M1 Macbook, I'm going to have a much poorer sense of how the things I'm working on would behave in production.
I thought that's what staging environments were for? Plus scale tests? A laptop provides a pretty poor proxy for a server environment behavior. For starters, they are not really the same spec, are they? Are you running a Xeon-based laptop?
It at least gets you in the same ballpark. I'm not allowed to hook a debugger up to anything in the staging environment, and it's not terribly fun to be stuck, for example, having to guess at how memory fences are behaving in production because all the machines where you can test things empirically have a different memory model.
Or, for example, there's one library I use that includes some inline assembly language routines. Which target SSE, not SVE. So, if we're targeting different ISAs, then my dev box isn't even executing the same code as what would be running in production.
> I'm not allowed to hook a debugger up to anything in the staging environment
That seems crazy to me. What bizarre excuse does your organization have for that policy?
To me, part of the point of a staging environment is to provide something as close as practical to prod in which to test, reproduce, evaluate, and investigate issues, be they performance, correctness, or what have you.
Even if it were allowed, it would still be awkward. I want to, as much as is practicable, find problems as early as possible, and not wait for them to get all the way to staging. I'm not really interested in making myself less able to do my job effectively just because I can.
Even if I'm using a JIT-ed product like C#/Java apps, I might still need to use OS-specific features that might differ from the ARM vs x86 flavour of Linux.
I develop and test against docker containers that run on a specific image + arch + base OS.
Even though my environment is supported on ARM, I am still not keen on using ARM servers even if I think it will work. There's just too much risk involved and I don't have the time to set it up and test it thoroughly.
Even in Python, OS differences and architecture differences pop up between testing, staging, and prod. It's annoying and can definitely cause user-facing problems.
With Python, some of the really useful libraries are written in C so you really need consistency between your environments if you don't want gotchas in your deployment pipelines.
One thing you might encounter is some C-binding building correctly on your machine but not in production (or vice-versa). Sure 99% of what you deploy is Python, Ruby, or JS... but that 1% in C/C++? Well.. you need that 1%.
He has a point, although that is not all there is.
Most web stuff dont deploy on x86, they deploy on VM or more specifically JVM. Which is someone else's problem. Amazon and Oracle are both spending resource making sure it works flawlessly.
I mean seriously, most doing Web Development dont even want to touch the VM.
You may want to ask Amazon, who is trying to get as many Graviton 2 produce as possible from TSMC because the demand for them are outstripping supply.
And all of that was before Apple even announced their switch to ARM on Mac.
For some workload it is half the cost on R6g than x86 instances. And for some like Twitter, they will invest into making sure it works with ARM. Those works get filter down the pipe. Medium-Large size companies see ecosystem matures and clear cost benefits they will move.
The high-end workstation and on-premise server markets overlap with the hyperscale cloud market. That's been true all along on X64 with high-end Xeon and Epyc parts.
"Hyperscale cloud" is just buzzword for "huge data center somewhere else" so there's not much of a difference except packaging and power (machines for hyperscale data centers often take direct DC power, not AC into one PSU per machine.)
Unlike POWER[1] and Itanium, you can very easily pick up ARM systems for experimenting with. That means there's way less of a burden to experimenting with new architecture. There's also ARM based Chromebooks and all sorts of devices, and you can also get ARM based servers for pennies per hour.
ARM's dominance in the cell phone market means it is ample popular enough, got lots of eyes on it, and increasing amounts of software is picking up dedicated optimisations for it.
I'm not sure what else you're really expecting. The hardware is there. The software is there. Very likely you could switch to ARM without noticing.
[1] Last time I mentioned this to someone involved in POWER architecture, they told me there were going to be cheap POWER based systems coming out to meet the "home hackers" market. I'm not paying particularly close attention, but I haven't seen anything yet?
Amazon made Graviton affordable. You even get a discount compared to running x86 instances.
Pay-As-You-Go is great for trying out new architectures: it's easy to justify spinning a few instances to test whether something can work under ARM. And if it does then convert existing instances to save money. No (hard to get unless you are a large business) dev boards to purchase.
I feel like you think that theres only two markets: "hyperscale cloud stuff" and colocation. Sure, nobody can drop $1000 on an ARM server and stick in 1U at their local colo. Do you want to? Is that what is fun for you? Or is it more about physical ownership?
When I first started developing on AWS, I bought the company a beefy server so we could run virtual machines on it to "test it locally". We bought a dual socket supermicro board and put our choice of Intel Xeons on it. It ended up being north of $2000 (ten+ years ago). At the time AWS c1.xlarge were $0.80 per hour. Paying per hour just felt wrong. And then, within a few months, we had a working system, and we were running 250 c1.xlarge for hours on end, and charging 50x for the end result. The $2000 machine sat idle and was a total waste of money. We developed on our local machines (a Mac), and deployed to test machines on AWS.
Now I pay some hosting company $x per month to host my eldest's minecraft server. I don't want to manage that shit! I have money but not time, and I use my time effectively. That means I don't waste my time buying and configuring servers.
Most devs are using mac, and all future macs are now Arm. I deploy to linux and develop on such an ARM mac, and I’ve already converted pretty much all my toolchain to ARM. Now choosing ARM is just a matter of telling Docker buildx to build for ARM.
Was wondering where they got their architectural license; it seems like they somehow obtained it indirectly from Applied Micro? Does anyone have more details as to how/when they acquired one?
I dont think anyone would know and I am not sure why that is important. And it is not like it needs some secret deal or special case for a company to acquire architectural license. Not to mention ARM is an investor in Ampere.
Architectural licenses are often secret deals, with the licensee being anonymous in many cases. As they are handed out fairly rarely, I personally find them fairly interesting to follow along.
My understanding is that this PR session is basically the announcement of the deal. True, it would be nice to know how long they've had a deal, but IMHO it's more interesting to know for how long the team has been working on the new design, and when it's slated to launch.
>In fact, Ampere explains that what the move towards a full custom microarchitecture core design was actually always the plan for the company since its inception, and their custom CPU design had been in the works for the past 3+ years.
So my guess is that they always had the license but never put out the announcement until they actually have their custom core.
Although in modern days PR speak a "custom" core could also be a custom ARM X-1 [1] type of custom. We will have to wait for more details.
>Microsoft in particular is a big addition to the customer list,
Google are working on their own ARM Server Chip. And we finally have ( some sort of ) confirmation Microsoft will be using Ampere.
At least Ampere will have fixed their Go to Market problem where no hyperscaler were committed to buying ARM instead of building their own. Along with Tencent Cloud which is a big surprise.
Which got me to question why Marvell lost the battle to Ampere.
Microarchitectures are used in -mtune= so there's an opportunity to tweak compilers to suit this design. But no changes are required: Aarch64 support is already present in popular compilers.
Well, the first Ampere product (eMAG) was based on the last X-Gene, and it was way behind contemporary Cortex/Neoverse cores. It is news that they took the time and effort to continue with custom uarch development, that they have confidence in the ability to make a good one.
Ampere were all in with N1, and it seemed that they'd stay with the Neoverse ecosystem for several generations. Everything coming out of them contact wise was very much Neoverse related, so for them to get up and say that they're ditching Neoverse after one generation is big news. Still SBSA compliant, but big news. Renee and Atiq brought over a lot of Intel SoC designers when they left.
If all the companies doing custom AArch64 microarchitectures had spent the effort building systems around ARM's designs instead, we'd probably have a thriving ARM server ecosystem by now.
Most of the custom AArch64 implementations are only semi-custom; they're mostly just derivatives of the ARM designs. The AWS Graviton chips are some of the few that are just using the ARM designs.
I don't think it's the wrong option for most of these companies; the ARM designs are really designed with a bit too much of a focus on power consumption and die area for server applications. The Neoverse V1 is the first ARM design really targeted at that market, and is shipping late this year AIUI. (That said, the Neoverse N2 is shipping not much later, and is a generation newer design, so we might end up with more N2 than V1, despite the V1 being a higher end part.)
There have been many failures in the past to outdo ARM's cores: Intel, AMD, Nvidia, Samsung, Qualcomm. Granted, some of those are ancient history or were more management failures than technical failures. It seemed to me that with ARM finally focusing on developing high performance cores, and the success of N1, the industry would coalesce around that. ARM has control over the ISA development which can influence and be influenced by microarchitecture designs, though they do work with Apple and Fujitsu somewhat. ARM gets to combine license fees from many customers into a single large R&D budget, much like TSMC. There's a huge risk that you spend billions for years and end up with custom cores that are worse than what ARM puts out.
So why design custom cores?
Maybe it's a necessity for a viable CPU company. Maybe it's too easy to create a custom CPU with stock ARM cores so unless you can do substantially better than that, all your biggest potential customers will just make their own: Amazon, Microsoft, IBM, Oracle, Baidu, Google, Tencent, Alibaba, are all perfectly capable of putting some stock cores together. Yes, the devil is in the details but I don't think the details are enough to base a company around. Maybe even if making a better microarchitecture is unlikely you have to try or be doomed to failure in the long run.
Maybe they believe their engineering is better. It's tempting to discount the value of individual contributors in projects involving hundreds or thousands of people. Maybe Ampere believe their engineers and/or managers are just better than the competition, and can beat them with fewer resources.
Maybe it's not as hard as it used to be. The received wisdom after decades of Intel dominance was to not even try to compete. Now we seem to be reaching a plateau in microarchitecture innovation. Yes, CPUs are still getting faster but the designs seem to have converged a lot. It certainly seems easier to catch up given that Apple, ARM, and AMD have all succeeded recently. Ampere also starts with an A so they're in good company.
Maybe it doesn't actually have to be substantially better. Maybe the N1 license fees are high and they just need something similar for less money. Maybe they just need something different that their sales team can sell as being better.
214 comments
[ 4.4 ms ] story [ 265 ms ] threadAnd using a custom uarch is also a statement to your customers, shareholders, competitors etc. that you mean business rather than just going the well-trodden path with ARM cores.
That's because a consequence of the second paragraph is that it's potentially business-profitable to make a "custom uarch" even if you make no use of the enormous scope for design changes.
The comment you replied to said "with a given ISA, how custom can the uarch be", implying that it would not be very custom.
You replied, in your first paragraph, that on the contrary, it could be pretty custom, with the implication being that it probably would be, because that's the value proposition that Ampere is presumably offering.
So your paragraph 1 is suggesting that the sentence "Ampere will now use a custom uarch" is an argument that Ampere's custom arch might well be pretty highly customized.
ON THE OTHER HAND....
Your second paragraph points out that simply being custom is a social signal (the signal of being, in your words, "that you mean business rather than just going the well-trodden path"). You argue (and I agree) that this social signal might make you more attractive to some customers. I.e. the signal might increase sales. This implies that it would be reasonable for Ampere to spend a certain amount on a barely-custom custom uarch, purely for sales/marketting reasons, as long as it didn't substantially harm performance. You know, because of the implication.
So your paragraph 2 is suggesting that the sentence "Ampere will now use a custom uarch" is NOT an argument that Ampere's custom arch has any particular need to be highly customized.
Well, Apple uses the ARM ISA for their A and M series chips, and but not ARM's microarchitecture, and their chips have significantly higher IPC than comparable parts from Qualcomm or Samsung. Similarly, Intel and AMD both implement the same x86 ISA, but the performance advantage has swung repeatedly between the two. Microarchitecture might be "in large parts" dictated by the ISA, but there's still enough left over for hardware designers to have a significant influence on the overall performance.
This is very much not the case. Just consider that, for example, Intel still supports running the same ISA that ran on 8086. The microarchitecture now running those instructions isn't at all like the 8086 microarchitecture. (Its running a bunch of other instructions too, but the points stands)
An example in the reverse direction, is that a some MIPS chip teams saw that MIPS was dying, and reused their MIPS microarchitectural designs to build ARM processors.
Sure, ISA can be designed assuming some things about microarchitecture, and then it can be inconvenient to change it. But not impossible. And during the transition to ARM64, ARM took the opportunity to remove things that were inconvenient for different microarchitectures (eg, directly accessible PC reg, changes to how condition codes work, etc)
Refer to RISC-V unprivileged spec, chapter one. Not dictating microarchitecture is one of its goals.
Personal take: it would be the end of them if they weren't.
I'm not sure that's true though..
With the way Apple operates, we have ten years before we can reasonably assume that they would change their architecture. Is RISC-V really going to be worth all the headaches of a transition in ten years?
"The company was founded in November 1990 as Advanced RISC Machines Ltd and structured as a joint venture between Acorn Computers, Apple Computer (now Apple Inc.) and VLSI Technology."
https://en.wikipedia.org/wiki/Arm_Ltd.#Founding
More details about ARM licensing:
"Finally at the top of the pyramid is an ARM architecture license. Marvell, Apple and Qualcomm are some examples of the 15 companies that have this license."
https://www.anandtech.com/show/7112/the-arm-diaries-part-1-h...
I can bet $100 on it being wrong. Especially the ARMv8 ( and v9 )
Long story short, it's probably not terribly utilitarian to have strong opinions about the subject when participating in an international forum such as this one.
I know virtually nothing about the internals, but that‘s also what people said about ARM.
> If X86 still competes I see no reason why RISC-V can't also
First RISC-V needs to catch up with the 40 years of x86 improvements that kicked out SPARC, Cray, SGI and others from high-end performace systems.
I'd suspect an ISA designed in the last few years with performance in mind (even if not a priority), wouldn't take as long to get to where the industry is now, but it's still a lot of years of focused effort required, and we'll see.
I don't have a horse in the race, except that I do like my experience to not evaporate; and I sincerly hope real mode segmented address edge cases aren't something I'd need to relearn on another ISA even though they're still (barely) relevant on x86 in early boot.
Saying X86 is 40 years work is also kind of stupid, as a huge amount of the ISA dead weight, and high performance implementations have their roots much earlier than that (e.g. Intel have tried to move on at least once and ended up coming back to the OOO superscalar paradigm).
1. Already ported.
2. Not dependent on modern performance, and thus well served by emulation.
Just shows the power of an establed ISA (all the software that runs on top of it) and how solid ARM's business model is.
The ISA is an interface, and as such may not be copyrightable or even patentable. Even if it was, we've had various interoperability exceptions, and one does need an ARM ISA to run a program compiled for ARM.
Besides, as far as I know ARM doesn't just license the ISA. It licenses cores. There's a good chance that if you make your own cores to implement an ARM ISA, you wouldn't have to pay any fee. You may however have to get around trademark, and not call your CPUs "ARM CPUs". Though I suspect "ARM compatible" would work perfectly (just like "IBM compatible" worked with third party PC vendors).
The terms are secret, but basically yes, AMD had access to 386? designs and what not as part of IBMs second source requirements with Intel, but Amd486 and up designs were AMD original with instruction sets under license from Intel, although the licenses were set up after release under litigation.
> Does Intel pay AMD a fee for using their 64 bit extensions?
Yes / sort of. Use of the AMD64 extentions was negotiated under the broad cross licensing between the two companies.
> Does anybody pay the inventor of the SSE and AVX instruction sets?
Do the persons involved get royalties? I'd guess not, but who knows. Would you have to pay more to get a license for them, almost certainly.
You'll note there's been a lot fewer x86 processor designs not from the big two over the past many years than there were in the late 90s. Some of that is because 'RISC is going to change everything', but a lot of it is becsause nobody can get an x86 license.
> Does anybody pays Nintendo for deploying emulators?
I don't think so. Patents are too old, and there's not a whole lot of non-Nintendo emulation in the commercial market (but I know Capcom has released some collections, of Megaman games, etc). If those types of releases started including systems with system roms, then you would start having copyright claims.
Nintendo has never seriously impeded system emulation; there's just no case to be made. ROM distribution is clear copyright violation though, of course.
I don't agree with that. The base ISA is highly optimised for high performance. Many of the decisions made are precisely because it makes it easier to design very wide superscalar CPUs. The vector extension is also looking like it'll be more efficient than ARMs.
What's missing, is instruction set extensions that makes it comparable to ARM/x86 across all workloads. And obviously it's far less mature in general.
RISC-V has been optimized for a single-purpose, being as simple as possible to be easily taught to students and implemented by them in a limited time.
It lacks many features required for high performance without hardware of excessive complexity, the most obvious being that RISC-V does not have decent addressing modes, so that the highest performance implementation reported until now (by Alibaba at the 2020 Hot Chips Conference) had to add a non-standard ISA extension to correct this.
Nobody remotely competent chooses RISC-V for "high performance" in any definition of that term.
RISC-V can be the right choice in many cases because:
1. No costs for using the RISC-V ISA
2. Easy customization with non-standard extensions
3. An already existing complete software development environment, with compilers, debuggers etc.
4. Acceptable performance at a given implementation cost
There is no need to invent extra fictitious advantages, like "high performance".
It is actually a replacement for MIPS in a more literal sense: The company owning MIPS has recently renamed itself to MIPS, and it abandoned MIPS ISA in favor of RISC-V ISA.
Do you have any proof that additional addressing modes would increase performance? What I remember from college and papers I've read is that more modes are generally a detriment to pipelining.
Maybe you're talking about "needing more instructions". You'd be wrong in this case. Using the compact instruction set gives an average of 15% more dense code compared to x86 and somewhere around 25-35% more dense compared to aarch64 (about equivalent density to thumb, but without the switching overhead that makes thumb slow).
"Xuantie-910: A Commercial Multi-Core 12-Stage Pipeline Out-of-Order 64-bit High Performance RISC-V Processor with Vector Extension"
From "VIII. NON-STANDARD INSTRUCTION SET EXTENSION"
Targeting at various industrial applications, XT-910 enables a set of custom non-standard instructions, additional to the standard RISC-V instructions. The non-standard instruction extension can be categorized into two groups based on the purposes - memory access enhancement, and basic arithmetic operation enhancement.
A. Memory access enhancement
Memory access instructions usually account for a high proportion in the total number of instructions, so enhancing memory access instructions can directly benefit the overall performance. By analyzing the mainstream applications running on RISC-V, we observed that for the basic RISC-V instructions there is still quite some room for improvement in memory access related instructions.
First, we support register + register addressing mode, and support indexed load and store instructions. This type of instruction extension reduces the usage of the registers for calculation and reduces the number of instructions for address generation, thereby effectively accelerating the data access of a loop body. Second, unsigned extension during address generation is supported. Otherwise, the basic instruction set does not support direct unsigned extension from 32-bit data to 64-bit data, resulting in too many shift instructions.
I'm not certain if they break out the results by individual optimization, but in Fig. 20 in the paper it looks like all their tweaks add up to a 20% boost over the standard RISC-V ISA. Pretty huge.
>I'm not certain if they break out the results by individual optimization
They don't, so it's not clear where the 20% comes from. They're using a compiler that optimizes for their microarchitecture, which might account for a lot of that. As for the mention of "extensions", it's not even clear to me whether they mean official RISC-V extensions such as IMAFD or custom extensions.
[0] https://riscv.org/technical/specifications/
(start with chapter 1 of the unprivileged spec)
As a practical counterexample to that FUD, it is also the ISA chosen by the Barcelona Super-computing Center EuroHPC[1] to design a new high performance CPU for future supercomputers.
[0]https://riscv.org/technical/specifications/
[1]https://www.bsc.es/news/bsc-news/bsc-working-towards-the-fir...
Generally, for RISC-V, look to China it seems?
However, RISC-V is so minimal that it might be possible to add it as a second ISA to a chip without much effort. On the other hand, it's so minimal that a JIT translator from RISC-V to the native ISA can be a valid alternative (see for instance https://carrv.github.io/2017/papers/clark-rv8-carrv2017.pdf).
Of course, it helps if the ISAs are at least broadly similar in terms of register space and available operations and memory ordering specifications. And the performance is in the details.
It's good news for open source hardware development. But bad news for USA and for people with security concerns. I don't know how comfortable I'd be with a Chinese designed CPU, Chinese compilers, and a Chinese kernel ... even if they were all open source.
The US Empire is corrupt, but its processes of decision making and power are relatively transparent (open elections, senate trials, etc.). The Chinese system is entirely opaque. In a sense, all citizens in China are ultimately completely vulnerable to the whims of the state ... there is no recourse for arbitrary detention, seizure of property, etc. This is a model China seeks to export in the long run ... either directly, or through affiliates.
America sucks ... but as people often say about Democracy, its the worst system of governance except all the rest.
I’ve studied Chinese politics and have reached the opposite conclusion to you.
Abu Ghraib wasn’t made public through courts at all.
How many other such places exist and still kept secret for now? The past would suggest there are at least several.
If you lived in America, you would see the huge amount of protests on the streets against the Iraq war and other international adventures. Also, US politicians with significant power regularly speak out against such adventures.
This is America's internal control mechanisms. There are no such mechanisms in China.
Anyway, there's no point discussing this further. Either you understand this level of nuance, your you inherently believe in the notion that "all countries are equally bad" type philosophy with no regard to how information is brought to light and how a country is constrained.
Guantanamo bay is still open, despite what happens there being illegal under Cuban, US and international law. Julian Assange and Chelsea Manning are still persecuted.
You either understand that your country is oppressing the entire world or you blindly believe everything your ruling class tells you.
I don't think you can patent trivial details of "API" but you can absolutely patent a given function of an ISA.
You probably shouldn't be able to (Alpha vs. MIPS, x86 etc.) but currently you can.
Assuming the default mode of operation is having just a few cores operating at 100% with the majority running at 0%, it's wasteful to not let those active cores run as fast as possible.
Obviously the default mode of operation is to run all cores, or very nearly all cores, at full tilt all of the time. This chip is designed to be garbage at few-threaded workloads.
That’s I suppose a simplification they can make by focusing only on “datacenter” while intel needs the same design to work from 1 socket to hundreds.
My message for people trying to make "ARM Server" CPUs a thing is that you have a real chicken or egg problem to solve, getting these things into the hands of people doing Linux development on x86-64 right now. Without a robust ecosystem of all the Taiwan-based motherboard manufacturers behind you, it's never going to get more than a few percent market share.
I've been a CTO for a decade+ and did try to get one the last time they made a splash.
The problem with this stance is that they can also keep using the non elitist platform, considering the elitist platform is inferior for many use cases.
No sparks...
Basically there was no way of getting your hands on them. They were interested only in "Serious customers".
Having seen this play out a number of times I don't think targetting that segment and only that segment is a great idea.
From a stack perspective, you can't really go it alone anymore. The total necessary software universe is too large to rebuild on a reasonable timescale, and too expensive to rebuild by oneself.
IBM is about the smallest scale that can do this -- and even they're leveraging decades of effort.
If the market isn't established then you may need to get traction with the dreamers and misfits.
I think the lack of availability certainly didn't help, but the architecture itself was probably the biggest downfall of the IA-64 platform. When it was introduced, the hardware was certainly advanced, but relied too much on software to get proper performance out of the chips. The product was doomed from the start.
Ampere will likely have entirely different problems bringing their architecture into the market, but I don't think Itanium ever stood a chance even if they'd sent out free chips to as many influential people and companies as possible.
The architecture was probably a fatal mistake on its own (even if Intel had disbanded its x86 line, the “older” RISC processors outperformed, often substantially) but ensuring that almost nobody saw anything close to what performance it could deliver definitely made it fatal. If Intel hadn’t been greedy trying to charge for compilers, the gap wouldn’t have been nearly as bad.
This must have been a huge part. Maybe ICC could squeeze more MIPS per dollar out of Itanium than x86, but if GCC can't, people are going to not buy Itanium rather than buy ICC.
I think that's the kind of issue they're talking about. If it had been easier for nerds in bedrooms to run Itanium, we'd've seen much better support for it in GCC etc. much sooner.
Back when I supported computational scientists, the total cost of the servers + compilers was so steep that even if everything had worked as well as the Itanium salespeople promised it would have needed to be many times faster to be worth the hassle of changing toolchains, especially since you had to pay up front for the hope that with a fair amount of work you'd at least hit the point of breaking even.
If Itanic had won, we'd still be basically where we are today from a hardware perspective, but with even less competition.
Apple made it happen on the client, but Amazon is making it happen on the server. The people who want to run their own DCs or hardware will end up part of the niche left on x86. I don't see Apple doing anything in the server space beyond providing minis like they do now.
iServer with 64 cores and 256 GiB DDR4 for only $ 699,999.95
You are off by an order of magnitude :)
If they are to be commercialized, I’d expect them to be part of a development stack related to Xcode, or some kind of AWS like services for applications developed for the Apple ecosystem.
Offering generalized compute would invite too much initial cost performance comparison and they couldn’t keep up with demand.
(I’m not sure whether that includes servers at large cloud providers, but I don’t think that matters. Unless there’s a huge performance advantage, I don’t see Amazon, Google or Microsoft buying Apple server CPUs)
I never did deliver for the OLPC project, but I tested a lot of things other people were working on. I also finally grokked the free software idea and became and engineer instead of a history teacher.
The $250 or so of prototype hardware has been repaid in testing, bug reporting other things I was able to do then. It sits on a shelf in my office to remind me how I got started, and what it mean to really be a part of a community that takes risks to invest in newcomers.
Once Raspberry Pi CM4 support is added, I assume that you would be able to work on drivers for PCIe devices as well. Besides, non-server vendors like NXP have released official boards with ARM ServerReady support.
I'm not affiliated with Avantek in any way. I just did a bunch of research looking to build/buy a desktop, and ARM was a contender, but I ended up building a beefy x86 machine with a Ryzen instead.
[0]: https://store.avantek.co.uk/arm-desktops.html
"I can pretty much guarantee that as long as everybody does cross-development, the platform won’t be all that stable. Or successful.
Some people think that “the cloud” means that the instruction set doesn’t matter. Develop at home, deploy in the cloud.
That’s bullshit. If you develop on x86, then you’re going to want to deploy on x86, because you’ll be able to run what you test “at home” (and by “at home” I don’t mean literally in your home, but in your work environment).
Which means that you’ll happily pay a bit more for x86 cloud hosting, simply because it matches what you can test on your own local setup, and the errors you get will translate better…
Which in turn means that cloud providers will end up making more money from their x86 side, which means that they’ll prioritize it, and any ARM offerings will be secondary and probably relegated to the mindless dregs (maybe front-end, maybe just static html, that kind of stuff).
Guys, do you really not understand why x86 took over the server market?
It wasn’t just all price. It was literally this “develop at home” issue. Thousands of small companies ended up having random small internal workloads where it was easy to just get a random whitebox PC and run some silly small thing on it yourself. Then as the workload expanded, it became a “real server”. And then once that thing expanded, suddenly it made a whole lot of sense to let somebody else manage the hardware and hosting, and the cloud took over. (All emphasis original)"
For example, if I'm building on Firebase with Cloud Functions I'm so far abstracted from the underlying hardware that these architecture specific issues are less important.
Similarly, if I'm working in Django/Python on AWS RDS, using an ARM server for my EC2 instance might be an issue ... but moving my RDS Postgres instance onto ARM might not make a difference.
I have no specific knowledge here but I imagine the x86-64 builds are far better tested, regarding correctness. As cmrdporcupine points out, the performance of the x86-64 builds will also have been better studied. Whether it's an issue in practice, I don't know, but if you're looking to minimize risk, there are good reasons to stick with x86-64.
I can certainly imagine a 'serverless' platform like Lambda or something where running on ARM is just an implementation detail (if it's not already).
Whether you're right or not, I think I agree with the idea.
It also seems to me that, in general, working with a different CPU architecture and instruction set implies that the new & improved stuff has to be significantly better to be worth the cost and risk.
At this point, is one really that much better than another? Are large improvements happening at the margin?
Another camel that'll poke it's head in the tent, in large/expensive embedded (which I realize that the parts in the article aren't aimed at) is whether a CPU and it's battlegroup of other stuff will be supported right off the bat by software infrastructure and later on by actually being available in the long run. You have to wonder how out on a limb anyone who used a Motorola 88k felt.
From 1984 to the iPhone, I believe it was the norm to develop Mac applications on Macs, except for a brief period when the very first models were starved for memory.
It is, but it introduces enough differences that you're not "at home"; indeed I'd say OSX-to-Linux is a bigger difference for development than x86-to-ARM.
Even more people use macbooks to develop for the browser, or to develop using platform-independent languages: Python, Ruby, Node, maybe even golang.
Quite a few people then package their backend code in a container and test it in a Linux VM which "Docker for Mac" helpfully provides.
But indeed the fact that Macs used to run on Intel, so the libraries you used in development were mostly that same versions of the same code as in production, must have been helping.
People only develop on MacOS because of how similar it is to Unix, not in spite of it. Go ahead, look at how many developers were using MacOS before OSX. I'll wait. The reason why people develop on Macs is because it's "close enough" to Linux to deploy with, and "good enough" as a desktop to keep tabs on most of your other apps.
> So while there may be some premium to being able to "develop at home", clearly many developers value other considerations more highly.
Let's clear this up: there is no development without development at home. If you work for a company as a developer, you'll be expected to maintain a machine that can consistently build and deploy your software. Unless you're working as a web developer (in which case, may god have mercy on your soul), you're probably going to end up using an x86 machine. Hell, my best friend is a die-hard Apple fan, and even he has admit that he can't really upgrade his Xeon iMac unless Apple offers him an upgrade within the x86 ecosystem.
Why can't he upgrade? (Genuine question)
There were plenty of other problems with pre-OSX MacOS.
> The reason why people develop on Macs is because it's "close enough" to Linux to deploy with, and "good enough" as a desktop to keep tabs on most of your other apps.
The differences between x86 OSX and x86 Linux are bigger than the differences between x86 Linux and ARM Linux, in my experience. So these machines are also "close enough" to ARM servers.
> there is no development without development at home. If you work for a company as a developer, you'll be expected to maintain a machine that can consistently build and deploy your software.
Most developers have a local development environment and a separate production environment. Developers place some value on having them be similar, but they're also happy to introduce differences between local and prod for the sake of other tradeoffs.
I wouldn't be at all worried about deploying my Ruby, Python, or Java app on ARM, having worked with x86 locally.
That is, as long as the Ruby, Python, and Java development teams themselves have been able to test on ARM hardware themselves!
I think Linus' comments still apply to those higher level languages. They all rely on platform dependent code.
Java less so, but the behavior and performance characteristics are definitely different.
I know Java has C extensions for some things too. I'm curious how much code is actually "pure Java", but I've actually rarely seen Java used at any of the places I worked at.
And then there are all the other native and system packages that you depend on. For example, I do a lot of work in Python, and I would be very hesitant to have anything but an Intel CPU in my workstation. Because that's what our servers run, and I know that a lot of packages I use include native code that has been carefully tuned for Intel CPUs. If I choose AMD or get an M1 Macbook, I'm going to have a much poorer sense of how the things I'm working on would behave in production.
That said, I'd be willing to at least try it. On the other hand, if work started talking about switching to ARM servers in production, I'd instantly be clamoring for a (non-M1) ARM workstation to develop on, because I need to know that I'm not going to get into trouble with packages that get a lot of love in the x86 versions of the native libraries but not so much on ARM.
This was a good argument a couple of decades ago. Now? Keep in mind that most devices in this planet are ARM-based, ever since we started talking about 'smartphones'. They have been running these interpreters for a long time now. Most applications and libraries of any importance have been ported.
> If I choose AMD or get an M1 Macbook, I'm going to have a much poorer sense of how the things I'm working on would behave in production.
I thought that's what staging environments were for? Plus scale tests? A laptop provides a pretty poor proxy for a server environment behavior. For starters, they are not really the same spec, are they? Are you running a Xeon-based laptop?
Or, for example, there's one library I use that includes some inline assembly language routines. Which target SSE, not SVE. So, if we're targeting different ISAs, then my dev box isn't even executing the same code as what would be running in production.
That seems crazy to me. What bizarre excuse does your organization have for that policy?
To me, part of the point of a staging environment is to provide something as close as practical to prod in which to test, reproduce, evaluate, and investigate issues, be they performance, correctness, or what have you.
Even if it were allowed, it would still be awkward. I want to, as much as is practicable, find problems as early as possible, and not wait for them to get all the way to staging. I'm not really interested in making myself less able to do my job effectively just because I can.
Nowadays a browser takes that role.
Having a workstation with the same CPU is definitly not an issue as Linus makes it to be.
I develop and test against docker containers that run on a specific image + arch + base OS.
Even though my environment is supported on ARM, I am still not keen on using ARM servers even if I think it will work. There's just too much risk involved and I don't have the time to set it up and test it thoroughly.
With Python, some of the really useful libraries are written in C so you really need consistency between your environments if you don't want gotchas in your deployment pipelines.
Most web stuff dont deploy on x86, they deploy on VM or more specifically JVM. Which is someone else's problem. Amazon and Oracle are both spending resource making sure it works flawlessly.
I mean seriously, most doing Web Development dont even want to touch the VM.
You may want to ask Amazon, who is trying to get as many Graviton 2 produce as possible from TSMC because the demand for them are outstripping supply.
And all of that was before Apple even announced their switch to ARM on Mac.
For some workload it is half the cost on R6g than x86 instances. And for some like Twitter, they will invest into making sure it works with ARM. Those works get filter down the pipe. Medium-Large size companies see ecosystem matures and clear cost benefits they will move.
"Hyperscale cloud" is just buzzword for "huge data center somewhere else" so there's not much of a difference except packaging and power (machines for hyperscale data centers often take direct DC power, not AC into one PSU per machine.)
ARM's dominance in the cell phone market means it is ample popular enough, got lots of eyes on it, and increasing amounts of software is picking up dedicated optimisations for it.
I'm not sure what else you're really expecting. The hardware is there. The software is there. Very likely you could switch to ARM without noticing.
[1] Last time I mentioned this to someone involved in POWER architecture, they told me there were going to be cheap POWER based systems coming out to meet the "home hackers" market. I'm not paying particularly close attention, but I haven't seen anything yet?
https://twitter.com/IanCutress/status/1387061860965437440
Pay-As-You-Go is great for trying out new architectures: it's easy to justify spinning a few instances to test whether something can work under ARM. And if it does then convert existing instances to save money. No (hard to get unless you are a large business) dev boards to purchase.
It's available but as you said, not at any reasonable price. The motherboard alone seems to be $5,000.
When I first started developing on AWS, I bought the company a beefy server so we could run virtual machines on it to "test it locally". We bought a dual socket supermicro board and put our choice of Intel Xeons on it. It ended up being north of $2000 (ten+ years ago). At the time AWS c1.xlarge were $0.80 per hour. Paying per hour just felt wrong. And then, within a few months, we had a working system, and we were running 250 c1.xlarge for hours on end, and charging 50x for the end result. The $2000 machine sat idle and was a total waste of money. We developed on our local machines (a Mac), and deployed to test machines on AWS.
Now I pay some hosting company $x per month to host my eldest's minecraft server. I don't want to manage that shit! I have money but not time, and I use my time effectively. That means I don't waste my time buying and configuring servers.
>In fact, Ampere explains that what the move towards a full custom microarchitecture core design was actually always the plan for the company since its inception, and their custom CPU design had been in the works for the past 3+ years.
So my guess is that they always had the license but never put out the announcement until they actually have their custom core.
Although in modern days PR speak a "custom" core could also be a custom ARM X-1 [1] type of custom. We will have to wait for more details.
[1] https://www.arm.com/products/cortex-x
Their first product (eMAG) was based on the last APM X-Gene (3?) cores.
Google are working on their own ARM Server Chip. And we finally have ( some sort of ) confirmation Microsoft will be using Ampere.
At least Ampere will have fixed their Go to Market problem where no hyperscaler were committed to buying ARM instead of building their own. Along with Tencent Cloud which is a big surprise.
Which got me to question why Marvell lost the battle to Ampere.
They also had two from-scratch developed microarchitectures.
I don't think it's the wrong option for most of these companies; the ARM designs are really designed with a bit too much of a focus on power consumption and die area for server applications. The Neoverse V1 is the first ARM design really targeted at that market, and is shipping late this year AIUI. (That said, the Neoverse N2 is shipping not much later, and is a generation newer design, so we might end up with more N2 than V1, despite the V1 being a higher end part.)
Apple and AWS seem to leave the competition behind.
Please, please, hold the applause...
There have been many failures in the past to outdo ARM's cores: Intel, AMD, Nvidia, Samsung, Qualcomm. Granted, some of those are ancient history or were more management failures than technical failures. It seemed to me that with ARM finally focusing on developing high performance cores, and the success of N1, the industry would coalesce around that. ARM has control over the ISA development which can influence and be influenced by microarchitecture designs, though they do work with Apple and Fujitsu somewhat. ARM gets to combine license fees from many customers into a single large R&D budget, much like TSMC. There's a huge risk that you spend billions for years and end up with custom cores that are worse than what ARM puts out.
So why design custom cores?
Maybe it's a necessity for a viable CPU company. Maybe it's too easy to create a custom CPU with stock ARM cores so unless you can do substantially better than that, all your biggest potential customers will just make their own: Amazon, Microsoft, IBM, Oracle, Baidu, Google, Tencent, Alibaba, are all perfectly capable of putting some stock cores together. Yes, the devil is in the details but I don't think the details are enough to base a company around. Maybe even if making a better microarchitecture is unlikely you have to try or be doomed to failure in the long run.
Maybe they believe their engineering is better. It's tempting to discount the value of individual contributors in projects involving hundreds or thousands of people. Maybe Ampere believe their engineers and/or managers are just better than the competition, and can beat them with fewer resources.
Maybe it's not as hard as it used to be. The received wisdom after decades of Intel dominance was to not even try to compete. Now we seem to be reaching a plateau in microarchitecture innovation. Yes, CPUs are still getting faster but the designs seem to have converged a lot. It certainly seems easier to catch up given that Apple, ARM, and AMD have all succeeded recently. Ampere also starts with an A so they're in good company.
Maybe it doesn't actually have to be substantially better. Maybe the N1 license fees are high and they just need something similar for less money. Maybe they just need something different that their sales team can sell as being better.
Subtle but significant difference. The company is sentence case now.