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

RISC-V Is Sloooow

marcin.juszkiewicz.com.pl

Post reply on HN
Print view View original

121–130 of 397 posts

Re: RISC-V Is Sloooow

#121

Post by adrian_b »

classichasclass wrote: post #80
rwmj wrote: post #43

Earlier quoted context omitted.

RISC-V doesn't have the pitfalls of Sparc (register windows, branch delay slots), largely because we learned from that. It's in fact a very "boring" architecture. There's no one that expects it'll be hard to optimize for. There are at least 2 designs that have taped out in small runs and have high end performance.

As a counterexample, I point to another relatively boring RISC, PA-RISC. It took off not (just) because the architecture was straightforward, but because HP poured cash into making it quick, and PA-RISC continued to be a very competitive architecture until the mass insanity of Itanic arrived. I don't see RISC-V vendors making that level of investment, either because they won't (selling to cheap markets) or can't (no…

I would not call PA-RISC boring. Already at launch there was no doubt that it is a better ISA than SPARC or MIPS, and later it was improved. At the time when PA-RISC 2.0 was replaced by Itanium it was not at all clear which of the 2 ISAs is better. The later failures to design high-performance Itanium CPUs make plausible that if HP would have kept PA-RISC 2.0 they might have had more competitive CPUs than with Itanium.

SPARC (formerly called Berkeley RISC) and MIPS were pioneers that experimented with various features or lack of features, but they were inferior from many points of view to the earlier IBM 801.

The RISC ISAs developed later, including ARM, HP PA-RISC and IBM POWER, have avoided some of the mistakes of SPARC and MIPS, while also taking some features from IBM 801 (e.g. its addressing modes), so they were better.

Re: RISC-V Is Sloooow

#122

Post by mananaysiempre »

bonzini wrote: post #67
balou23 wrote: post #18

Earlier quoted context omitted.

TBH I still don't really get how it's different from MIPS. As far as I can tell... Loongson seems to be really just MIPS, while LoongArch is MIPS with some extra instructions.

LoongArch is, on a first approximation, an almost RISC-V user space instruction set together with MIPS-like privileged instructions and registers.

Wait, this is a modern-ish ISA with a software-managed TLB, I didn’t realize that! The manual seems a bit unhappy about that part though:

> In the current version of this architecture specification, TLB refill and consistent maintenance between TLB and page tables are still [sic] all led by software.

https://loongson.github.io/LoongArch-Documentation/LoongArch...

Re: RISC-V Is Sloooow

#123

Post by nine_k »

adgjlsfhk1 wrote: post #89
adrian_b wrote: post #71

Earlier quoted context omitted.

RISC-V does not have the pitfalls of experimental ISAs from 45 years ago, but it has other pitfalls that have not existed in almost any ISA since the first vacuum-tube computers, like the lack of means for integer overflow detection and the lack of indexed addressing. Especially the lack of integer overflow detection is a choice of great stupidity, for which there exists no excuse. Detecting integer overflow in hardw…

> On the other hand, detecting integer overflow in software is extremely expensive this just isn't true. both addition and multiplication can check for overflow in <2 instructions.

Fewer than two is exactly one instruction. Which?

Re: RISC-V Is Sloooow

#125

Post by Findecanor »

fidotron wrote: post #40
rbanffy wrote: post #2

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…

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

Because today, getting a fast CPU out it isn't as much an engineering issue as it is about getting the investment for hiring a world-class fab.

The most promising RISC-V companies today have not set out to compete directly with Intel, AMD, Apple or Samsung, but are targeting a niche such as AI, HPC and/or high-end embedded such as automotive.

And you can bet that Qualcomm has RISC-V designs in-house, but only making ARM chips right now because ARM is where the market for smartphone and desktop SoCs is. Once Google starts allowing RVA23 on Android / ChromeOS, the flood gates will open.

Re: RISC-V Is Sloooow

#126

Post by adgjlsfhk1 »

lizknope wrote: post #94
fidotron wrote: post #40

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…

Of your list, Qualcomm and Nvidia are fairly likely to make high perf Riscv cpus. Qualcomm because Arm sued them to try and stop them from designing their own arm chips without paying a lot more money, and Nvidia because they already have a lot of teams making riscv chips, so it seems likely that they will try to unify on the one that doesn't require licensing.

Re: RISC-V Is Sloooow

#127

Post by adgjlsfhk1 »

Findecanor wrote: post #125
fidotron wrote: post #40

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…

Because today, getting a fast CPU out it isn't as much an engineering issue as it is about getting the investment for hiring a world-class fab. The most promising RISC-V companies today have not set out to compete directly with Intel, AMD, Apple or Samsung, but are targeting a niche such as AI, HPC and/or high-end embedded such as automotive. And you can bet that Qualcomm has RISC-V designs in-house, but only making…

It's very much both. You need millions of dollars for the fab, but you also need ~5 years to get 3 generations of cpus out (to fix all the performance bugs you find in the first two)

Re: RISC-V Is Sloooow

#128

Post by [deleted] »

primis wrote: post #27
throwaway27448 wrote: post #25

[flagged]

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.

[deleted]

Re: RISC-V Is Sloooow

#129

Post by sitharus »

hackyhacky wrote: post #78
adrian_b wrote: post #71

Earlier quoted context omitted.

RISC-V does not have the pitfalls of experimental ISAs from 45 years ago, but it has other pitfalls that have not existed in almost any ISA since the first vacuum-tube computers, like the lack of means for integer overflow detection and the lack of indexed addressing. Especially the lack of integer overflow detection is a choice of great stupidity, for which there exists no excuse. Detecting integer overflow in hardw…

> On the other hand, detecting integer overflow in software is extremely expensive, increasing both the program size and the execution time considerably, Most languages don't care about integer overflow. Your typical C program will happily wrap around. If I really want to detect overflow, I can do this: add t0, a0, a1 blt t0, a0, overflow Which is one more instruction, which is not great, not terrible.

Because the other commenter wasn’t posting the actual answer, I went to find the documentation about checking for integer overflow and it’s right here https://docs.riscv.org/reference/isa/unpriv/rv32.html#2-1-4-...

And what did I find? Yep that code is right from the manual for unsigned integer overflow.

For signed addition if you know one of the signs (eg it’s a compile time constant) the manual says

  addi t0, t1, +imm
  blt t0, t1, overflow
But the general case for signed addition if you need to check for overflow and don’t have knowledge of the signs

  add t0, t1, t2
  slti t3, t2, 0
  slt t4, t0, t1
  bne t3, t4, overflow
From what I’ve read most native compiled code doesn’t really check for overflows in optimised builds, but this is more of an issue for JavaScript et al where they may detect the overflow and switch the underlying type? I’m definitely no expert on this.

Re: RISC-V Is Sloooow

#130

Post by thesuperbigfrog »

cogman10 wrote: post #64
hrmtst93837 wrote: post #47

Earlier quoted context omitted.

[flagged]

While true, it's typically not going to be impactful on system performance. There's a reason, for example, why the linux distros all target a generic x86 architecture rather than a specific architecture.

Ubuntu recently added a more specific target for AMD64v3:

https://discourse.ubuntu.com/t/introducing-architecture-vari...

Post reply on HN