POLL: x86 vs ARM vs RISC-V; What is your favourite CPU ISA?

[FlameTail]

Vote below! Tell in the comments which one you voted for and the reason.

 

[gdansk]

I've only handwritten MIPS assembly (showing my age now I guess). The others I wouldn't feel right to have a preference.

 

[FlameTail]

I chose ARM because;

1. Two of my favourite CPU microarchitectures: Apple Silicon and Qualcomm Oryon both use ARM.

2. ARM is an open ISA unlike x86 which is a duopoly. On the hand RISC-V is even more open than ARM, and entirely free- but the issue is that the RISC-V ecosystem as it stands now is not as mature as ARM or x86.

3. ARM core designs are generally much more efficient than their x86 counterparts. I am not a professional or gamer, so I don't care about maximum performance. Instead I highly appreciate great efficiency.

 

[gdansk]

ARM is an open ISA unlike x86 which is a duopoly.

Counterpoint: ARM is more strictly controlled than x86. There's no way to legally make a ARM core without paying ARM on their terms. Meanwhile you can get an Intel-compatible core without paying a cent to Intel (or even AMD). ARM can introduce whatever features it wants on its schedule and stop innovation in its ISA by threatening to sue for derivative intellectual property. AMD and Via/Zhaoxin can add whatever extensions they want to x86 even if Intel would rather they didn't. In fact, that's how we got x64 and the first AES-accelerating instructions for x86. But x86 has a limited number of grandfathered in players and x64 fewer still.

 

[lightmanek]

I vote for Motorola CISC MK68k ... it's the most widespread (as in distance) architecture in our Solar System

 

[Gideon]

I vote for Motorola CISC MK68k ... it's the most widespread (as in distance) architecture in our Solar System

Oh don’t make me weep for the good old Amiga days!

I was only 8 when Commodore filed for Bankrupcy and I moves on to PCs, but still have my most fond computing memories from 1990 -1994 (tbf probably because of the young age not in spite of it)

 

[Shivansps]

What ever happened with MIPS?

As licensing thing goes RISC-V is better, but that dosent means much, if someone were to make the best cpu in the world with RISC-V you can be sure it is not going to be open source.

As for ARM, with all these attempts at reaching PC-level performance they have forgotten what ARM was all about, being power-efficient first and foremost.

The funny part is one of the more important progress in the last few years were in the field of microcontrollers, things like the ESP8266 and the ESP32 changed everything, to the point that petty much killed the original market the RPI was targeted at. These are RISC cores.

 

[eek2121]

x86 because it dominates the performance and compatibility sector and powers all of DIY.

Outside of that, RISC-V is my absolute favorite because of the lack of patents and because it is evolving quickly. (ARM has been around about as long as x86, for comparison, and people have been claiming ARM will kill x86 for about as long as well. I think RISC-V will kill them both so hah! )

 

[FlameTail]

As for ARM, with all these attempts at reaching PC-level performance they have forgotten what ARM was all about, being power-efficient first and foremost.

If you are referring the ARM Cortex X4...

 

[Shivansps]

If you are referring the ARM Cortex X4...

it is just part of the problem, the other part is big-low design went to hell because they failed to provide a good OOO small core, they created the "mid cores" that are actually big cores because of it and now people, for some reason, seem suprised that a phone can reach 25W.

I also dislike, very much, their policy with drivers for their Mali GPUs, but thats not the subject of this thread.

 

[FlameTail]

it is just part of the problem, the other part is big-low design went to hell because they failed to provide a good OOO small core, they created the "mid cores" that are actually big cores because of it and now people, for some reason, seem suprised that a phone can reach 25W.

I also dislike, very much, their policy with drivers for their Mali GPUs, but thats not the subject of this thread.

So you are focusing on ARM's own Cortex designs?

In the meantime we have Apple and Qualcomm(Nuvia) designing efficient high-performance ARM cores.

 

[Shivansps]

So you are focusing on ARM's own Cortex designs?

In the meantime we have Apple and Qualcomm(Nuvia) designing efficient high-performance ARM cores.

Part of the reason why Apple M1 was so successfull is their small cores (on top of the big ones), other ARM cpu had no way to match that whiout going all big cores.

 

[FlameTail]

Part of the reason why Apple M1 was so successfull is their small cores (on top of the big ones), other ARM cpu had no way to match that whiout going all big cores.

Indeed. Apple's OOO small E-core is definitely a huge W.

Qualcomm is also developing an E-core. You can check out the Snapdragon Thread for details.

 

[Nothingness]

I started writing assembly code in 1983 on a Z80. I then switched to MC68K and then SPARC. I also wrote an experimental compiler MIPS backend. I now do a lot of Arm assembly language.

To my eyes x86 has always been an abomination; too bad Motorola was late and Intel won the IBM PC. The ISA is unorthogonal and a horrible mess. I never developed a lot of x86 code; though I'm able to read and write some, it's too much of a torture. Game: look at the SHR CL semantics, how sane is that?

As far as RISC-V goes, its shortcomings from an ISA point of view are glaring (no register + register indexing, really?), it's obvious it started as a student project. Oh and the marketing noise around it disqualifies it. It's funny looking at them playing catch up with Arm ISA and having to pile up extensions to counter balance the initial weaknesses. The only advantage it has is reduced cost for the chip makers.

Arm is a modern ISA in its AArch64 incarnation. I'd say the system side has grown too much: the virtual memory subsystem is huge and has lots of features; but that's expected for chips that will go from phones to servers with virtualization.

Needless to say my vote goes to Arm

 

[igor_kavinski]

Vote below! Tell in the comments which one you voted for and the reason.

Why did you forget the IBM POWER ISA?

WHY?

What do you have against the magnificent beasts running the entire financial sector???

*CRIES OUT IN SHEER PAIN*

Why I would continue to bet on IBM Power Systems

When you look at concentrated high compute, data churning systems in the market today, you will still find the name of IBM very much figure amongst the leaders out there. While the Mainframe continues to reign in the BFSI sector and other highly intensive online transaction processing domains, IBM’s

www.linkedin.com

 

[Nothingness]

Why did you forget the IBM POWER ISA?

WHY?

What do you have against the magnificent beasts running the entire financial sector???

*CRIES OUT IN SHEER PAIN*

Why I would continue to bet on IBM Power Systems

When you look at concentrated high compute, data churning systems in the market today, you will still find the name of IBM very much figure amongst the leaders out there. While the Mainframe continues to reign in the BFSI sector and other highly intensive online transaction processing domains, IBM’s

www.linkedin.com

AS/400 and COBOL also are a thing!

Joke aside, you reminded me I also programmed on IBM Cell. I still have a PS3 with Linux installed on it. What a funny chip it was!

I'd say it comes second after Arm

 

[igor_kavinski]

Joke aside, you reminded me I also programmed on IBM Cell. I still have a PS3 with Linux installed on it. What a funny chip it was!

I'd say it comes second after Arm

Please share more!

Because I still own a FAT PS3 with Linux on it too. It shall never see the internet ever!

 

[Nothingness]

Please share more!

Because I still own a FAT PS3 with Linux on it too. It shall never see the internet ever!

Same here! Thing is, it's stored in a box somewhere (along with a PS2 Linux), so I'm not sure it still works.

I used to think heterogeneous computing was the future. In a way I still think it is, but not the way the Cell did it. I think dedicated blocks (NPU, GPU, DSP, etc.) are much more efficient, especially with modern API.

 

[igor_kavinski]

I think dedicated blocks (NPU, GPU, DSP, etc.) are much more efficient, especially with modern API.

What are you playing with these days development-wise?

 

[Nothingness]

What are you playing with these days development-wise?

From a hobby point of view, I mainly do development in computational number theory on AVX-512 and NEON (and would do SVE if I had a machine supporting it).

PS - Yes, I said x86 stinks, this just says I know it first hand, but AVX-512 is not that bad

 

[naukkis]

As far as RISC-V goes, its shortcomings from an ISA point of view are glaring (no register + register indexing, really?), it's obvious it started as a student project. Oh and the marketing noise around it disqualifies it. It's funny looking at them playing catch up with Arm ISA and having to pile up extensions to counter balance the initial weaknesses. The only advantage it has is reduced cost for the chip makers.

Basic principle of RISC-design is to do ISA that makes hardware implementation easy for high execution speed. There's actually very high knowledge behind Risc-v. For assembly programmer not having fancy indexing addressing is a case for complaining - but for high speed RISC ISA it's a plain obvious thing - don't mix alu and load/store operations. For simple hardware implementations doing hardware indexed load/store-instructions are actually beneficial as they are easy to optimize - but for future proof ISA for very high performance cores RISC-V got it right. Doing load/store indexing by general purpose hardware pretty much automatically optimizes load/store execution with all hardware capabilities execution ALU hardware has - making it much more plausible to optimize load/store engine to run much farther ahead than with hardware indexing modes.

You know that modern Arm and X86 cpu designs have thing called AGU. That's alu unit responsible of generating those complicated indexed addressing addresses for each load. Risc-V design don't need them - they can expand their load/store capabilities without need to add more AGU-units. And with those hardware indexing instruction sets - actually when more complex indexing modes are used load latency is longer by one clock cycle. By Risc-V scheme that is avoided. Of course Risc-v type addressing can be used with arm and x86 too, but why to have instructions which when used made cpu performing worse.

Other key points of Risc-V is that SIMD. SVE tries to be SIMD-vector length agnostic but isn't - Risc-V other hand doesn't have SIMD hardware at all - instead it have vector ISA. Vector ISA presents vectors as loops of scalar instructions - and execution hardware, when done right, is totally vector length agnostic, those instructions can be executed with scalar or SIMD hardware at any given register length.

 

[moinmoin]

I'd vote for ForwardCom by Agner Fog, the guy known for the detailed microarchitecture guides. It's a "best of" ISA taking the good parts of different ISAs while avoiding common pitfalls.

 

[Tuna-Fish]

I've only handwritten MIPS assembly (showing my age now I guess). The others I wouldn't feel right to have a preference.

Tick RISC-V, then, it's the direct philosophical descendant.

I'd vote for ForwardCom by Agner Fog, the guy known for the detailed microarchitecture guides. It's a "best of" ISA taking the good parts of different ISAs while avoiding common pitfalls.

I am not a fan. ForwardCom looks to me too much like a system overfitted to simple problems, at the cost of making everything worse for larger problems. My favorite quote is from the memory management page:

It is possible to obtain top memory performance with these features if the programmer observes some discipline to avoid memory fragmentation. Difficult cases that produce memory fragmentation may include unpredictable heap size, memory-mapped files, large databases, and large multiuser systems.

So it has problems with literally all the cases that actually matter?

Also, it seems to me that a lot of thought has been put into how the architecture is used by the developers, but not enough into how it's implemented in hardware. And where thought has been put towards that, it's mostly for fairly trivial considerations, such as regularity of decoding, yet there are orthogonal addressing modes that allow any instruction to read from memory.

(edit) Also, it shuffles way too much system complexity to the operating system while ignoring the problems it creates. No, it is not okay to ask for programs to know how much memory they need before they begin to execute.

 

[Thunder 57]

I've only handwritten MIPS assembly (showing my age now I guess). The others I wouldn't feel right to have a preference.

MIPS assembly is still taught (last I checked) at many universities for students just learning about assembly. It is easier IMHO than x86 assembly.

 

[igor_kavinski]

It is easier IMHO than x86 assembly.

Those students must really go "WTF!" when they have to do x86 assembly in real life