Hacker News Reader

Comment by byefruit | Hacker News Reader

This is relatively misinformed piece of writing.

There is little to no reason why high performance RISC-V implementations can not achieve performance comparable to modern "CISC" cores.

As other commenters have said, VLIW doesn't suddenly make the problem go away and no amount of compiler magic is going to fix the fundamental issue that memory access on a modern processor is highly non-uniform and scheduling is not something that can be done statically ahead of time.

RISC-V is designed to be extended with complex instructions and accelerators and that's the scalable part.

View on HN

I think it depends on how you interpret "reduced"

- Does it mean reducing the actual number of instructions in the ISA?

- Does it mean reducing the functionality of each instruction to it's absoloute minimum?

These are similar, and overlapping in places. You can also do one without the other.

I think that the base RISC-V ISA does both to a perhaps unhelpful degree. As soon as you want a RISC-V core to be competative with other peer ISAs, you need a bunch of the extensions, which minimises the value in calling it reduced in the first place. At the least, it exposes a possible dichotomy between "reduced-ness" and "usefullness".

Reduced in RISC means nothing today. It made sense in the '80 when a RISC ISA allowed implementing a fully pipelined cpu on a single chip. Today RISC basically means a load store architecture with easy to decode ISA, with usually but not necessarily fixed size instructions.

RISC-V even with the basic extention set is still far smaller then the competition. And when you add the 'V' extention it is also considerably smaller comperative SIMD instructions.

A comperable RISC-V core in terms of feature, will always have less instruction.

Indeed, but that just means RISC-V designers have pursued the "less instructions" goal for its own sake. Having less instructions is not inherently beneficial. It can actually be detrimental: common operations require more instructions.

https://gist.github.com/erincandescent/8a10eeeea1918ee4f9d99...

The RISC-V designers disagree. A number of typical patterns can be optimized easly by macro-op fusion in higher performance cores. The benfit is a decoder that has an incredibly small size, minimizing minimal core for RISC-V.

Also RISC-V preferes less in in the core spec because if you have application that really needs something there will be standard extentions to add it.

> minimizing minimal core for RISC-V

Again: why should I care about that? As a user, I care about big desktop-class cores, not academic minimal cores that fit on FPGAs. Small decoder is not a benefit for real world usage.

> there will be standard extentions to add it

That is, there will be fragmentation.

> Again: why should I care about that?

Have you considered that the world doesn't revolve around you?

You are infact wrong, many 'real world' uses like how small these cores can be.

And given that many SoC now have lots and lots of small cores in them, having those cores be as small as possible is beneficial.

> That is, there will be fragmentation.

Yes. There will be fragmentation because an industry that is so broad, in terms of minimal soft cores to massive HPC systems, so having a true one-size-fits-all would have been doomed from the beginning and was never a viable design goal.

RISC-V is design to approch the problem of a universal open-source ISA. It knows that avoiding fragmentation is impossible and thus they tried to build something that makes fragmentation managable both in terms of the organisation of the standard and in terms of the tools.

Well, RISC-V is ultimately just a trademark/brand, as is Advanced RISC Machines (ARM), nothing stops them standardizing a CISC-like extension and keeping the brand if needed.

Reply on news.ycombinator.com