Comment by monocasa
2 days ago
> The second category for big-compute is actual desktops and SBCs that do interactive computation, browsing, gaming, and other such "desktop work". I do not expect RISC-V to be a serious player at the top of this market. Simply put, the architecture is not designed for it, as pointed out above. Additionally, this market has the margins to afford licensing a much-better-designed aarch64 core from ARM, and gain proper support from a much larger corpus of software. Before you get your megaphone to shout about "openness", please note that the openness of the RISC-V spec is not relevant here at all, because an open spec does not magically materialize a well-designed out-of-order core for you for free. And if someone were to design a good out-of-order core, they would not be giving it away for free. An open spec does not mean every implementation is free.
I basically disagree with this. Not because this isn't the current state of things (it absolutely is), but because we're at a bit of an inflection point where mooore's law has proved itself to be an scurve, and we're very clearly well into the top half of it. From that, gate counts per core will also start to ossify, and that means the longer latency for getting an open core design off the ground initially will also start to make sense.
I'm not sure the gate count argument works in RISC-V's favour.
While RISC-V is quite optimised for gate count for small cores; In large wide OoO cores the variable length encoding really bulks out the decoders.
You basically have the same requirement as x86, where you have to attempt to decode a 32-bit instruction every 16-bits (because there is no alignment guarantee for 32-bit instructions), and then cancel out the invalid ones. It's not quite a bad as x86, you only need to look at two bits, but it still forms a long dependency chain, and probably requires at least one extra decode stage with complex routing to pick out all the valid instructions.
You don't really have to have a separate decoder every 16-bits. What you have is a length decoder every 16 bits (so just a single nand gate over the first two bits versus a huge chunk of the prefix/opcode part of the decoder for x86), which then feeds into a set of muxes for the actual decoders. The actual increase in complexity ends up coming from the critical path of the stack up of length selection affecting start addresses (and therefore mux selections) for later instructions in the block, but even that's not nearly as bad as it sounds because you can use the same base trick behind a carry lookahead adder. When I did some experiments a while back, it ended up being less than half a pipeline stage overhead versus fixed width instructions kind of across the board.
So not nothing, but very far from a deal breaker even for wide 8, 10, or even 12 wide cores.
> you can use the same base trick behind a carry lookahead adder
YESSSS.
I've been pointing this out for years and years.
By the point that you're looking at the same propagation delay as a common 64 bit adder you're decoding 64 chunks of 16 bits per cycle. That's 128 bytes, or a 32-64 instructions wide decoder.
That is so much wider than anyone is making or contemplating — or that even makes sense given the size of basic blocks — that it's just a non-issue.
3 replies →
Yes... but then you are kind of wasting a pipeline stage on nothing more than length decoding.
I suspect a design with a full decoder every 16-bits might actually win on everything but gate count, mostly because it can deal with variable length instructions and variable number of μops per instruction in the same step. A decoder that doesn't output a μop because it was clobbered by a previous instruction, can be handled the same was as a decoder that didn't output a μop because of μop fusion.
Actually, that approach might actually eliminate the need for the extra pipeline stage (just at the cost of gates).
It's certainly not a deal breaker. But it's a valid criticism of the ISA.
2 replies →
Nobody in high-performance does fixed-width instructions that allow lineary scaling parallel decoders. Arm basically requires certain instructions to be cracked into multiple uops before rename. That ends up analougus to decoding compressed instructions. RVC increases complexity before decode, how much that impacts things idk.
I don't believe this will impact performance in practice, because nothing forces CPU vendors to implement fast compressed instructions. If compressed instructions become slower than non compressed instructions as the instruction decoders get wider, compilers will stop emitting them in the future.
> […] we're at a bit of an inflection point where mooore's law has proved itself to be an scurve […]
Well. May's law[0], which states that:
effectively counterbalances Moore's Law and, with continued technological process improvements and optimisations, the proverbial arm's race is likely to continue for a very, very long time – just a few days I was reading a wonderful article from 1998 on the state-of-the-art DEC Alpha 21264 CPU which mentioned the 21264 and POWER3 as the world's most complex CPU's each boasting 15+ million transistors and also mentioned the equally state-of-the-art 0.18 micron processes. The 3 old year M3 Max design, in comparison, supplies over 90 billion transistors to the mainstream consumer.
Humans are resourceful, after all.
[0] https://en.wikipedia.org/wiki/David_May_(computer_scientist)...
That's sort of orthogonal to what I'm saying.
And the M5 doesn't have 500B transistors. We're well into the beginning of the ossification. Hell, it arguably started ~2006 with the end of dennard scaling leaving us with Tomasulo OoO cores being the design that makes the most sense for application cores, just getting wider over time as we get more gates.
Eventually CPUs and GPUs converge: huge numbers of CPUs with wide vector units.
Whom do you expect to work for free to design you a state-of-the-art core?
The same kind of people that 'worked for free' to develop Linux.
If those people build cores like linux kernel is built design-wise, i will PAY to watch the spectacle.
You do realize that Linux got basic SMP support 3 years after NT, and it was shaky for a while after? It still does not have reliable sleep-wake. And it only added native async file i/o in 2019, while NT has had it on the same hardware since 1993? So.. i'll expect an in-order core with an IPC south of 0.5 that cannot exit low power sleep 30% of the time in a decade or so.
11 replies →
Most Linux devs have been corporate employees getting paid to develop it for a very long time. It's not the early 90's any more.
1 reply →
Linux is decent for its core use cases, but it is far from a solid pro-grade OS in a lot of areas... and in the areas it did get there, it took a long time to get there.
5 replies →
The future set of people who once would have "work(ed) for free to design you a state-of-the-art kernel"? If the tail is long enough passionate hobbyists will do it because they love it...eventually.