Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Addressing Criticism of RISC-V Microprocessors

erik-engheim.medium.com

Post reply on HN
Print view View original

141–149 of 149 posts

Re: Addressing Criticism of RISC-V Microprocessors

#141

Post by avianes »

jhgb wrote: post #138

> In RISC-V the equivalent would require a whole 3 different instructions I'm surprised that it wasn't pointed out that this should probably be eliminated by a compiler transformation. Rather than loading from r0+r1<<2 and incrementing r1 by one every loop iteration, surely it might be possible to load from just r0 and increment it by 4 every loop iteration?

We don't need indexed loads only for loops. But even within loops, you may need indexed load.

One simple example: when you do loop unrolling, you must access elements n+4, n+8 and n+12 etc.

Re: Addressing Criticism of RISC-V Microprocessors

#142

Post by jhgb »

avianes wrote: post #141
jhgb wrote: post #138

> In RISC-V the equivalent would require a whole 3 different instructions I'm surprised that it wasn't pointed out that this should probably be eliminated by a compiler transformation. Rather than loading from r0+r1<<2 and incrementing r1 by one every loop iteration, surely it might be possible to load from just r0 and increment it by 4 every loop iteration?

We don't need indexed loads only for loops. But even within loops, you may need indexed load. One simple example: when you do loop unrolling, you must access elements n+4, n+8 and n+12 etc.

True, there are other uses. However some people seem to be pointing out that on average, the RISC-V code is still smaller on average.

As for unrolling, isn't this a job for RV64V?

Re: Addressing Criticism of RISC-V Microprocessors

#143

Post by tsmi »

ansible wrote: post #111
tsmi wrote: post #96

Earlier quoted context omitted.

I agree mostly with Keller's take but I think he left of one key factor, the quality of the software tool chain. The x86 tool chains are amazing. They're practically black magic in the kinds of optimizations they can do. Honestly, I think they're a lot of what is keeping Intel competitive in performance. ARM tool chains are also very good. I think they're a lot of the reason behind why ARM can beat RISCV in code spac…

I don't know that such a heavy investment in the toolchains for RISC-V are actually needed. If you look at generated code, it seems fairly straightforward. There aren't a lot of tricks or anything.

It's not so much "tricks" that one needs to look out for.

The compiler has just tons of internal heuristics on when and when not to apply various code transformations. Those heuristics, first off may not even be applicable for your platform of choice, and even if they are, their magic numbers aren't necessarily tuned well to the platform and application at hand.

Here is a well written and concise case study, albeit somewhat old (2010), that illustrates what I am talking about. The results of variations measurements will have changed since then but the overall high level situation hasn't. If you read the paper, in your mind, just replace every instance of x86 with ARM and every instance of ARM with RISCV and you'll get the idea.

https://ctuning.org/dissemination/grow10-03.pdf

Re: Addressing Criticism of RISC-V Microprocessors

#144

Post by tsmi »

brucehoult wrote: post #120
tsmi wrote: post #88

Earlier quoted context omitted.

People argue over these minimal differences for good reasons. If = binary size, and I'm buying ROM in volume to hold that binary, +10% ROM address space can easily cost more than the ARM license. That can matter quite a lot for adoption. Especially in the short term. Obviously, priorities differ and change as a function of time but as the saying goes, the only thing worse than making a decision with benchmarks is mak…

In 64 bit land, RISC-V has consistently the smallest code size. RV64GC, not even using the new things in the B extension that will make code smaller again. Some data from Ubuntu 21.10 for amd64, arm64, and riscv64: https://www.reddit.com/r/RISCV/comments/tik718/addressing_cr...

I only brought up the binary size thing to give a concrete example based off the article and the parent's comment. I am totally sure the situation is fluid and changing.

My high level point is: changes in "objective measurement" have costs in the same way that license, governance and ecosystem have costs. And "objective measurement" can easily overwhelm the others, especially at scale, and therefore they should not be dismissed as unimportant.

Re: Addressing Criticism of RISC-V Microprocessors

#145

Post by brucehoult »

klelatti wrote: post #74
KerrAvon wrote: post #71

Earlier quoted context omitted.

Have the ARM AArch64 designers ever commented on this? They intentionally left out any kind of compressed instructions, and certainly Apple at least cares a lot about code size.

Try this at 34:30 - from Arm’s architecture lead Richard Grisenthwaite. Earlier he says that several leading micro architects think that mixing 16 bit and 32 bit instructions (Thumb2) was the worst thing that Arm ever did. https://m.soundcloud.com/university-of-cambridge/a-history-o...

He explicitly specifies that those micro-architects are at companies OTHER than ARM.

His own opinion appears to be that the worst thing ARM ever did was T2EE, designed for JIT compilers and compilers for dynamic languages. He says that by the time the chips came out compiler technology had advanced to the point that it was no longer useful and no one else used it.

A couple of other points picked up in the talk:

- He reverses Hennessy and Patterson wrt SPARC and MIPS.

- A64 effort started in 2007. So it took 5 years to freeze/publishing, the same as RISC-V.

- A64 architects thought code density is no longer important. Some people definitely disagree with that. At the time they probably thought amd64 was the only competition and matching/beating that was good enough.

- he seems to be regretting the 2nd operand shift because it fell naturally out of the 1985 micro-architecture, but it's a burden now. And yet it was included in A64 -- presumably because the initial processor pipelines had it anyway, because they supported A32. But now we have A64-only CPUs.

- LL/SC was the wrong thing to do.

Re: Addressing Criticism of RISC-V Microprocessors

#146

Post by renox »

audunw wrote: post #52
dontlaugh wrote: post #23

It’s nice to have an open ISA, don’t get me wrong. However, trade offs matter. Compressing instructions may improve density, but it makes them variable length. This is a big barrier to decoding in parallel, which is very important to high performance cores.

Regular base instructions are always 32-bit, compressed are always 16-bit, and they're always aligned. I don't think there's a problem decoding them in parallel. You always know where the opcodes will be located in a 32-bit word - or set of 32-bit words - you're trying to decode. What I've been wondering is how difficult it is to fuse instructions when the compressed instructions you're trying to fuse isn't aligned t…

> ou always know where the opcodes will be located in a 32-bit word - or set of 32-bit words - you're trying to decode.

Uh? In RISC-V with the C extension, 32bit instructions are 16-bits aligned, so no you don't.

Re: Addressing Criticism of RISC-V Microprocessors

#147

Post by znwu »

snvzz wrote: post #128
znwu wrote: post #124

Earlier quoted context omitted.

Yes, the author's defence for Myth #1 does not strike me as a correct defence from the RISC-V perspective. Going to compressed instruction and compressed macro-op fusion is way overkill for the very basic indexed load/store problem.

The actual hardware cost of this case of "macro-op fusion" is negligible.

Yes it is negligible. The problem is that indexed load/store is a non-issue. There are ready-to-use simulation data that shows indexed load/store has minimal impact on dynamic code size.If someone uses an overkill feature to explain a non-issue, then it seems like nonsense.

Imaging someone uses quantum gravity to explain why Australians stand upside down on a globe.

Re: Addressing Criticism of RISC-V Microprocessors

#148

Post by snvzz »

znwu wrote: post #147
snvzz wrote: post #128

Earlier quoted context omitted.

The actual hardware cost of this case of "macro-op fusion" is negligible.

Yes it is negligible. The problem is that indexed load/store is a non-issue. There are ready-to-use simulation data that shows indexed load/store has minimal impact on dynamic code size.If someone uses an overkill feature to explain a non-issue, then it seems like nonsense. Imaging someone uses quantum gravity to explain why Australians stand upside down on a globe.

macro-op fusion is not rocket science.

Re: Addressing Criticism of RISC-V Microprocessors

#149

Post by znwu »

snvzz wrote: post #148
znwu wrote: post #147

Earlier quoted context omitted.

Yes it is negligible. The problem is that indexed load/store is a non-issue. There are ready-to-use simulation data that shows indexed load/store has minimal impact on dynamic code size.If someone uses an overkill feature to explain a non-issue, then it seems like nonsense. Imaging someone uses quantum gravity to explain why Australians stand upside down on a globe.

macro-op fusion is not rocket science.

Then write up an actually meaningful array processing function and translate it into asm is even less rocket science.

The author starts with a apparently meaningless `int x = a[i];`, but did not ask an obvious question before digging in: what usually goes before and after this statement and together what will they produce? A formal RISC-V code analysis usually does not go like this.

`int x = a[i];` is the kind of expression that strikes you as useful at the first glance, but then nothing. If you visit an array, then on x64/ARM/RISC-V, they are all compiled down to 2 instructions per iteration. Not 1 vs 2 vs 3 as suggested by the article. RISV-V may have one or two more instructions outside the loop but that's it.

Post reply on HN