191–200 of 397 posts
Earlier quoted context omitted.
Hey! I get this is a throwaway account so you might not answer, but I really, really don't like opening an article and having the first thing I see in a thread be someone calling the author a slur. There are ways of expressing insult without bringing intellectual disabilities into the mix.
For future readers: throwaway27448's comment used to say something completely different, featuring the r-slur, and then immediately edited.
Earlier quoted context omitted.
All of those things are solved with modern extensions. It's like comparing pre-MMX x86 code with modern x86. Misaligned loads and stores are Zicclsm, bit manipulation is Zb[abcs], atomic memory operations are made mandatory in Ziccamoa. All of these extensions are mandatory in the RVA22 and RVA23 profiles and so will be implemented on any up to date RISC-V core. It's definitely worth setting your compiler target appr…
You're correct but I guess my thoughts are if we're going to wind up with a mess of extensions, why not just use x86-64?
X86-64 also has “profiles” which tell you what extensions should be available. There is x86-64v1 and x86-64v4 with v2 and v3 in the middle.
RVA23 offers a very similar feature-set to x86-64v4.
You do not end up with a mess of extensions. You get RVA23. Yes, RVA23 represents a set of mandatory extensions. The important thing is that two RVA23 compliant chips will implement the same ones.
But the most important point is that you cannot “just use x86-64”. Only Intel and AMD can do that. Anybody can build a RISC-V chip. You do not need permission.
Earlier quoted context omitted.
It's 4k on x86 as well. Doesn't seem to hurt so bad -- at least, not enough to explain the risc-v performance gap.
Hmm? x86 has supported much larger “huge” page sizes for ages.
See, for example, https://www.pingcap.com/blog/transparent-huge-pages-why-we-d...
Earlier quoted context omitted.
> RISC-V will get there, eventually. Not trolling: I legitimately don't see why this is assumed to be true. It is one of those things that is true only once it has been achieved. Otherwise we would be able to create super high performance Sparc or SuperH processors, and we don't. As you note, Arm once was fast, then slow, then fast. RISC-V has never actually been fast. It has enabled surprisingly good implementations…
I think the bigger question is does RISC-V need to be fast? Who wants to make it fast? I'm a chip designer and I see people using RISC-V as small processor cores for things like PCIE link training or various bookkeeping tasks. These don't need to be fast, they need to be small and low power which means they will be relatively slow. Most people on tech review sites only care about desktop / laptop / server performance…
Don't blame the ISA - blame the silicon implementations AND the software with no architecture-specific optimisations. RISC-V will get there, eventually. I remember that ARM started as a speed demon with conscious power consumption, then was surpassed by x86s and PPCs on desktops and moved to embedded, where it shone by being very frugal with power, only to now be leaving the embedded space with implementations optimi…
In some cases RISC-V ISA spec is definitely the one to blame: 1) https://github.com/llvm/llvm-project/issues/150263 2) https://github.com/llvm/llvm-project/issues/141488 Another example is hard-coded 4 KiB page size which effectively kneecaps ISA when compared against ARM.
The problem is decades of software being written on a chip that from the outside appears not to care.
Earlier quoted context omitted.
Per https://en.wikipedia.org/wiki/Transistor_count , even an 8051 has 50K transistors, which reinforces my claim that 26K really doesn't seem like a big ask for an MCU core. Whether that means a barrel shifter is worth it or not is a totally orthogonal question, of course. (Although I do have to eat my words here - I didn't check that Wikipedia page, and it does actually list a ~6K RISC-V core! It's an experimental a…
I don't know if that construction might allow for a more efficient transistor count and it's totally impractical - 1KHz clock speed, 1-bit ALU, etc. - for almost any purpose, but it is technically a RISC-V implementation significantly smaller than 26K That sounds like a microcoded RISC-V implementation, which can really be done for any ISA at the extreme expense of speed.
Maybe other CPU's have it as well, though I do not have enough information on that.
Earlier quoted context omitted.
But RISC-V is a _new_ ISA. Why did we start out with the wrong design that now needs a bunch of extensions? RISC-V should have taken the learnings from x86 and ARM but instead they seem to be committing the same mistakes.
It is a reduced instruction set computing isa of course. It shouldn't really have instructions for every edge case. I only use it for microcontrollers and it's really nice there. But yeah I can imagine it doesn't perform well on bigger stuff. The idea of risc was to put the intelligence in the compiler though, not the silicon.
Earlier quoted context omitted.
But RISC-V is a _new_ ISA. Why did we start out with the wrong design that now needs a bunch of extensions? RISC-V should have taken the learnings from x86 and ARM but instead they seem to be committing the same mistakes.
It was kind of an experiment from start. Some ideas turned out to be good, so we keep them. Some ideas turned out not to be good, so we fix them with extensions.
Earlier quoted context omitted.
Hmm? x86 has supported much larger “huge” page sizes for ages.
Yes, and Linux. at least historically, has not used them without explicit program opt-in. Often advice is to disable transparent huge pages for performance reasons. Not sure about other operating systems. See, for example, https://www.pingcap.com/blog/transparent-huge-pages-why-we-d...
Earlier quoted context omitted.
In some cases RISC-V ISA spec is definitely the one to blame: 1) https://github.com/llvm/llvm-project/issues/150263 2) https://github.com/llvm/llvm-project/issues/141488 Another example is hard-coded 4 KiB page size which effectively kneecaps ISA when compared against ARM.
Regarding misaligned reads, IIRC only x86 hides non-aligned memory access. It's still slower than aligned reads. Other processors just fault, so it would make sense to do the same on riscv. The problem is decades of software being written on a chip that from the outside appears not to care.