1. If x64 wasn't already dominant and had the same market share as ARM, would you choose x64? Why?
2. With x64's current dominance, would you buy a ARM system as your primary one, knowing that you'll have significant difficulties developing for the majority of current market share?
1) You're almost certainly decoding into u-ops even if you chose RISC because you'll have uarch features like a seperate pipe line for the AGU and the load store queues, atomics that have to wait to go out all the way to L2 for fairly arbitrary lengths of time, etc. You can see this in cores as simple as BOOM, and it's opinion of the RISC-V community that macro op fusion of prescribed clauses is the way to go.
2) These decoders are a drop in the bucket when compared to OoO circuitry and power budget.
3) The complex addressing modes and memory RMW operands are effectively a way to address physical registers while consuming no architectural registers, and very few bits of I$. Yes, x86 is ancient and isn't as optimal as it could be from a huffman encoding perspective (hlt is a single byte opcode!), but it's pretty damn good overall. Better than AArch64 at code density and therefore I$ pressure. As an aside, I'm sorta curious what a CISC-V would look like, and if it would set a new bar.
I've been toying with the idea of literally having decoding as decompression, where there's a special instruction to change the dictionary. I guess this'd be tantamount to implementing the decoder as an FPGA, but I'm hoping there's some reasonable version where a fairly non-dense "base encoding" becomes a pretty optimal bit stream.
That being said, my experiments were hardly conclusive and I'd absolutely love to be proven wrong.
More specifically a core where the heart is being sequenced by Tomasulo's algorithm, and probably a large bypass network linking the functional units together.
I would pick the one which performed the best on my workload.
Assuming everything was equal; performance, performance per watt, software support, market share, price to performance: I would pick ARM because I think the competitive landscape is more diverse. x86 is effectively an AMD-Intel duopoly, especially with the cross-licensing agreements.
It's a lot easier to start working with ARM IP, which means there should be more competitors, which should translate to better future performance improvements. Even today, we see many more companies competing in this space (Ampere, Marvell, Qualcomm, Apple to a degree), not to mention startups looking to develop their own ARM chips.
[1] https://techcrunch.com/2020/04/29/arm-is-offering-early-stag...
I develop on a Windows laptop and deploy to Linux all of the time. I have some Python programs that have native dependencies. I still develop on Windows, push and the CI/CD pipeline runs on Linux and packages a Windows build.
But even with my first job out of college back in the 90s, I was writing C code that I developed on Windows and was cross compiled for DEC VAX and Stratus VOS mainframes.
Should be “packages a Linux build”
“ I was writing C code that I developed on Windows and was cross compiled for DEC VAX and Stratus VOS mainframes.”
Of course cross compiles is not the correct terminology. We built the same code on the target machines.
Mainframes do it, as means to integrate C and C++ into their language environments.
Back in the early mobile OS wars, there was a company selling J2ME like stack, but using C and C++ instead.
Then there is the LLVM bitcode used by Apple on iOS and watchOS (which happens to be more platform neutral than regular LLVM bitcode).
Oh and WebAssembly and MSIL as well.
LLVM proprietary Apple own internal fork, as used in iOS and watchOS, is another matter.
As a matter of fact, there is a WWDC talk about how it allowed the seamless migration of 32 to 64 on watchOS.
https://mobile.twitter.com/clattner_llvm/status/104696072464...
Apple does whatever they feel like with their proprietary fork, to the point that Apple's clang also gets its own column on cppreference.
Just like Sony and Nintendo haven't contributed anything back to LLVM that would disclose any capability from their consoles.
I tweeted @atp and let them know that the transcript was returning a 404. They have since fixed it.
https://atp.fm/205-chris-lattner-interview-transcript
John Siracusa: The same thing I would assume for architecture changes, especially if there was an endian difference, because endianness is visible from the C world, so you can’t target different endianness?
Chris Lattner: Yep. It’s not something that magically solves all portability problems, but it is very useful for specific problems that Apple’s faced in the past.
Only peripherally related to your point, but I develop with Python on Windows and found that deploying to Linux, while in possible, can be a hassle in practice.
For instance, I use turbodbc on Windows to access SQL Server databases via ODBC. This works fine.
However, when I try to port the same code to ARM Linux (on Raspberry Pi), I learn that ODBC has dependency on the native ODBC driver which doesn't exist on the ARM platform. So I have to jump through all kinds of loops to compile FreeTDS and unixODBC, which aren't trivial. Not only that, I had to cross-compile on an x64-Linux VM to the ARM architecture because the Raspberry Pi itself didn't have enough disk space for gcc and such.
I think cross-architecture compilation isn't the issue -- it's cross-platform deployment, especially when there's no parity in dependency availability.
Patents have a 20 year lifespan, most of the x86_32 ones have expired, but x86_64 is just barely still covered (the first publication was in 2000, and first commercial product was on AMD Opteron/Athlon64 in 2003). So it's probably just a matter of time before the userland emulation stuff is further extended, although we won't get anything newer than SSE2 for the same reason.
It is simply the business model changes. The older I get the more I am convinced it isn't the technical that changes or determines the outcome, it is the value proposition.
Not to mention no one "choose" x86. They chose Intel, or Intel CPU that still currently offer top performance under 10 - 16 Core.
Try doing that with ARM and tell me under what limited circumstances would you buy ARM laptop/desktop/workstation.
CPUs are at a stage where AMD and Intel are doing great in non battery constrained setups and with battery constraints you will only get better battery life if you don't make the CPUs sweat. In server/workstation design I would expect AMD and Intel to beat the crap out of ARM anything just because how much optimized they are in that space owing to massive use.
So except for frothing at mouth idiots that keep droning about this there isn't much value for the normal customer in buying ARM anything and lose on all fronts - software availability, build flexibility, compatible hardware availability and even performance for many cases. (Spare me teh Geekbench please.)
It does make sense for Apple to market their own CPUs to people who are into that type of thing - it's more control, more money and least dependence for Apple - all round win for them if they can pull it off. But it's not going to be easy unless they have something that is hugely better and overcomes at least some of the disadvantages.
I think this might be one of the motivations for Apple to switch to it's own CPUs instead of just switching to a different x86-64 CPU like AMD's Ryzen. Apple would be able to lock MacOS to the hardware like iOS and the iPhone.
Download apps only from Mac App Store, make it easy for people 100% in Apple ecosystem to do what they need to do (XCode, browsing, store apps, multi tasking) and they're good to go. They already charge premium for the hardware - not having to pay Intel will fatten the margins, with app store revenue and maybe banning 3rd party browsing engines they can get exactly what they have always wanted and so long as they provide people with some macOS features - terminal access (even if controlled) and multitasking etc. - people in the Apple ecosystem aren't going to care.
Of course it maybe gradual and it maybe not so restrictive - they may allow 3rd party app installations and make it harder like they have already done in a way.
Anandtech:
"This year, the A13 has essentially matched best that AMD and Intel have to offer "
https://www.anandtech.com/show/14892/the-apple-iphone-11-pro...
All at, as far as I can tell, a small fraction of the power consumption / thermal load.
So imagine a featherweight 12" MacBook with roughly the CPU performance of a much larger/heavier Intel laptop and the same or better battery life.
"This year, the A13 has essentially matched best that AMD and Intel have to offer – in SPECint2006 at least."
So yeah your comment is business as usual for Apple fan - taking comments and benchmarks out of context, comparing apples to oranges and just being generally dense to support some narrative. I.E. Nothing closer to the reality of having ARM CPUs beat AMD or Intel if I wanted to build a server or workstation or even a big powerful laptop with not optimized for email and browsing battery life.
SPEC doesn’t agree with your characterization of their benchmark.
“The SPEC CPU® 2006 benchmark is SPEC's industry-standardized, CPU-intensive benchmark suite, stressing a system's processor, memory subsystem and compiler.”
Neither does Wikipedia:
“SPECint is a computer benchmark specification for CPU integer processing power. It is maintained by the Standard Performance Evaluation Corporation (SPEC). SPECint is the integer performance testing component of the SPEC test suite”
https://en.wikipedia.org/wiki/SPECint
Nothing about energy efficiency, and notice the definite article “the” in front of “integer performance testing component”.
So SPECint tests general compute tasks, such as compiling, XML processing and running Perl programs.
Of course you can combine the perf measurements of SPECint with power consumption measurements to arrive at an efficiency measure, if you so choose.
The other benchmark was SPECfp, which focuses on scientific computing tasks such fluid dynamics, quantum chemistry etc.
So tasks you are unlikely to perform on...your iPhone. The A13 still does well, but not as well as on integer, presumably because Apple just didn’t focus on putting idle resources on their iPhone chip.
Increasing FP performance when you have great integer performance is straightforward, afaik: just add more FPU resources.
But leaving that aside, it is also a single threaded performance measure which is nice but not quite a big deal for desktop / workstation / server workloads. It's not very convincing that they will have a 12 core part for workstation that I can use (leaving aside the fact that I won't be able to run what I want on it) - that will perform much better than AMD/Intel in real world workloads including virtualization etc. So I still maintain that narrowly focused performance benchmarks Geekbench or SpecInt mean very little in factoring OP's question on whether you will replace your primary system with ARM - the other CPUs are also limited to what Apple's CPUs can run - not Java stuff for example.
ARM as a whole had lot of time to compete with others in desktop/workstation/server market and there is little evidence they got anywhere big.
I think this is a very small issue.
The reason why it's hard to develop for ARM today is that reasonably powerful (read: non-phone) ARM processors are not very common. The barrier for developing on ARM is that you have to explicitly purchase another ~$500 laptop in order to test on ARM. Also, libraries generally support x86 but not necessarily ARM. With small desktop market share, the expense is often not worth it.
On the other hand, x86 processors are ubiquitous, and if you're a developer, you can almost certainly find a old laptop or desktop with an x86 processor laying around to test your software on (especially if you're in the demographic to buy relatively expensive MacBooks). Also, since most people use x86, it makes sense to invest in that market.
TL;DR: ARM -> x86 barrier to entry is much lower because x86 processors are so common, x86 opportunity is much more lucrative, and most libraries already support x86.
Here is one example of what you get for 50 dollars:
https://www.hardkernel.com/shop/odroid-c4/
This is a quadcore 2GHz 64bit board that can run Android / Ubuntu 20 / Wayland / WebGL / Linux Kernel 5.4 / Vulkan.