4 ms·

> 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 exp

> 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.

dmitrygr 2mo ago
Whom do you expect to work for free to design you a state-of-the-art core?
- monocasa 2mo ago
  The same kind of people that 'worked for free' to develop Linux.
  - dmitrygr 2mo ago
    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.
    - monocasa 2mo ago
      > You do realize that Linux got basic SMP support 3 years after NT? Linux started about three years after NT did. And NT could only support 64 processors for a long time when Linux could support thousands. > It still does not have reliable sleep-wake. Neither does NT really. Both depend on ACPI for the systems you're talking about, and it's the platform interface that's ultimately fucked. > And it only added native async file i/o in 2019, while NT has had it on the same hardware since 1993 And has beaten NT on IO throughput for decades, and even now windows ships with a linux kernel integration because running Linux on a hypervisor is far batter for filesystem ops than running those on NT. And the new async I/O API was so good that NT adopted it wholesale and didn't even bother changing the name. https://learn.microsoft.com/en-us/windows/win32/api/ioringapi/ https://learn.microsoft.com/en-us/windows/win32/api/ioringap... > 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. There are already open source OoO RISC-V cores. But the point originally isn't to be some Linux fan boy (I've written a decent amount of NT kernel code, and have a lot of respect for NT and the things it did right). It's to point out how the upcoming changes inherent to how chips are made and the latencies between gate count targets will better support open collaboration. And once that's supported properly, open source has a tendency to kind of snowball.
      - dmitrygr 2mo ago
        We shall see :) When my iPhone or laptop is no longer running aarch64, i'll happily admit i had been wrong
        monocasa 2mo ago
        I mean, Apple is different from pretty much every other manufacturer here. They collborated in the design of aarch64, and a rumored to own a lot of the base IP themselves which they've cross licensed with ARM. It's very close to AMD:Intel::Apple:ARM when it comes to aarch64. That heavily changes the licensing costs. My point isn't that RISC-V is markedly better, but instead that it's equivalent from a perf achievable from in the same nexus of PPA and NRE effort. So there's no reason for Apple to take the pain of a leap with no real gain, but NRE losses. I would expect to see RISC-V Android phones (probably initially out of China, despite ARM China) within the next few years. They've been busy bees since RVA23 was ratified with a bunch of Chinese companies making changes to optimize AOSP for RVA23. I've also heard on the grapevine that NT already has a RISC-V port internally, but take that with whatever grain of salt you feel like. But Microsoft has already been contributing to the RISC-V specs (they contributed to Ztso for instance).
  - api 2mo ago
    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.
    - dismalaf 2mo ago
      > but it is far from a solid pro-grade OS in a lot of areas... Insane take given all the things that run on Linux...
      - pocksuppet 2mo ago
        It's server-grade. Not desktop-grade.
        dismalaf 2mo ago
        Tell that to Valve or the millions who use it as a desktop. Also, have you used Windows recently?
        api 2mo ago
        I keep saying Linux can win on desktop by just sitting still while Windows sucks more and more.
        pocksuppet 2mo ago
        It is, but it's a pyrrhic victory, because neither of them is actually good.
  - dismalaf 2mo ago
    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.
    - monocasa 2mo ago
      That's why I put 'worked for free' in quotes like that.
- rablackburn 2mo ago
  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.
phire 2mo ago
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.
- monocasa 2mo ago
  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.
  - phire 2mo ago
    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.
inkyoto 2mo ago
> […] 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: Software efficiency halves every 18 months, compensating Moore's Law. 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)#May's_law https://en.wikipedia.org/wiki/David_May_(computer_scientist)...
- monocasa 2mo ago
  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.
  - api 2mo ago
    Eventually CPUs and GPUs converge: huge numbers of CPUs with wide vector units.

dmitrygr 2mo ago

Whom do you expect to work for free to design you a state-of-the-art core?

monocasa 2mo ago
The same kind of people that 'worked for free' to develop Linux.
- dmitrygr 2mo ago
  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.
  - monocasa 2mo ago
    > You do realize that Linux got basic SMP support 3 years after NT? Linux started about three years after NT did. And NT could only support 64 processors for a long time when Linux could support thousands. > It still does not have reliable sleep-wake. Neither does NT really. Both depend on ACPI for the systems you're talking about, and it's the platform interface that's ultimately fucked. > And it only added native async file i/o in 2019, while NT has had it on the same hardware since 1993 And has beaten NT on IO throughput for decades, and even now windows ships with a linux kernel integration because running Linux on a hypervisor is far batter for filesystem ops than running those on NT. And the new async I/O API was so good that NT adopted it wholesale and didn't even bother changing the name. https://learn.microsoft.com/en-us/windows/win32/api/ioringapi/ https://learn.microsoft.com/en-us/windows/win32/api/ioringap... > 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. There are already open source OoO RISC-V cores. But the point originally isn't to be some Linux fan boy (I've written a decent amount of NT kernel code, and have a lot of respect for NT and the things it did right). It's to point out how the upcoming changes inherent to how chips are made and the latencies between gate count targets will better support open collaboration. And once that's supported properly, open source has a tendency to kind of snowball.
    - dmitrygr 2mo ago
      We shall see :) When my iPhone or laptop is no longer running aarch64, i'll happily admit i had been wrong
      - monocasa 2mo ago
        I mean, Apple is different from pretty much every other manufacturer here. They collborated in the design of aarch64, and a rumored to own a lot of the base IP themselves which they've cross licensed with ARM. It's very close to AMD:Intel::Apple:ARM when it comes to aarch64. That heavily changes the licensing costs. My point isn't that RISC-V is markedly better, but instead that it's equivalent from a perf achievable from in the same nexus of PPA and NRE effort. So there's no reason for Apple to take the pain of a leap with no real gain, but NRE losses. I would expect to see RISC-V Android phones (probably initially out of China, despite ARM China) within the next few years. They've been busy bees since RVA23 was ratified with a bunch of Chinese companies making changes to optimize AOSP for RVA23. I've also heard on the grapevine that NT already has a RISC-V port internally, but take that with whatever grain of salt you feel like. But Microsoft has already been contributing to the RISC-V specs (they contributed to Ztso for instance).
- api 2mo ago
  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.
  - dismalaf 2mo ago
    > but it is far from a solid pro-grade OS in a lot of areas... Insane take given all the things that run on Linux...
    - pocksuppet 2mo ago
      It's server-grade. Not desktop-grade.
      - dismalaf 2mo ago
        Tell that to Valve or the millions who use it as a desktop. Also, have you used Windows recently?
        api 2mo ago
        I keep saying Linux can win on desktop by just sitting still while Windows sucks more and more.
        pocksuppet 2mo ago
        It is, but it's a pyrrhic victory, because neither of them is actually good.
- dismalaf 2mo ago
  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.
  - monocasa 2mo ago
    That's why I put 'worked for free' in quotes like that.
rablackburn 2mo ago
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.

phire 2mo ago

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.

monocasa 2mo ago
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.
- phire 2mo ago
  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.

inkyoto 2mo ago

> […] 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: Software efficiency halves every 18 months, compensating Moore's Law. 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)#May's_law https://en.wikipedia.org/wiki/David_May_(computer_scientist)...

monocasa 2mo ago
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.
- api 2mo ago
  Eventually CPUs and GPUs converge: huge numbers of CPUs with wide vector units.