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

161–170 of 397 posts

Re: RISC-V Is Sloooow

#161

Post by snvzz »

Findecanor wrote: post #132
topspin wrote: post #6

Earlier quoted context omitted.

I keep checking in on Tenstorrent every few months thinking Keller is going to rock our world... losing hope. At this point the most likely place for truly competitive RISC-V to appear is China.

Tenstorrent is supposedly taping out 8-wide Ascalon processors as we speak, with devboards projected to be available in Q2/Q3 this year. BTW. Keller is also on the board of AheadComputing — founded by former Intel engineers behind the fabled "Royal Core".

>Ascalon tape out

Supposedly happened earlier this year. Tenstorrent says devboards in Q3.

Now we just wait.

Re: RISC-V Is Sloooow

#162

Post by sitharus »

sitharus wrote: post #129
hackyhacky wrote: post #78

Earlier quoted context omitted.

> 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, +i…

A bit more reading shows there's a three instruction general case version for 32-bit additions on the 64-bit RISC-V ISA. I'm not familiar with RISC-V assembly and they didn't provide an example, but I _think_ it's as easy as this since 64-bit add wouldn't match the 32-bit overflowed add.

  add t0, t1, t2
  addw t3, t1, t2
  bne t0, t3, overflow

Re: RISC-V Is Sloooow

#163

Post by snvzz »

rbanffy wrote: post #4
dmitrygr wrote: post #3

Earlier quoted context omitted.

IF you care to read the article, they indeed do not blame the architecture but the available silicon implementations.

I did read it. A Banana Pi is not the fastest developer platform. The title is misleading. BTW, it's quite impressive how the s390x is so fast per core compared to the others. I mean, of course it's fast - we all knew that. And don't let IBM legal see this can be considered a published benchmark, because they are very shy about s390x performance numbers.

>I did read it. A Banana Pi is not the fastest developer platform. The title is misleading.

Ironically, its SoC (spacemiT K1) is slower than the JH7110 used in the first mass-produced RISC-V SBC, VisionFive 2.

But unlike JH7110, it has vector 1.0, making it a very popular target.

Of course, none of these pre-RVA23 boards will be relevant anymore, once the first development boards with RVA23-compatible K3 ship next month.

These are also much faster than anything RISC-V currently purchasable. Developers have been playing with them for months through ssh access.

Re: RISC-V Is Sloooow

#165

Post by sidewndr46 »

weebull wrote: post #98
newpavlov wrote: post #44

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.

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?

Re: RISC-V Is Sloooow

#166

Post by whaleofatw2022 »

sidewndr46 wrote: post #165
weebull wrote: post #98

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?

Because the ISA is not encumbered the way other ISAs are legally, and there are use cases where the minimal profile is fine for the sake of embedded whatever vs the cost to implement the extensions

Re: RISC-V Is Sloooow

#167

Post by wk_end »

snvzz wrote: post #153
pezezin wrote: post #142

Earlier quoted context omitted.

The 32-bit ARM architecture included a barrel shifter as part of its basic design, as in every instruction had a shift field. If a CPU built in 1985 with a grand total of 26 000 transistors could afford it, I am pretty sure that anything built in this century could afford it too.

26k is a lot of transistors for an embedded MCU. You'd be excluding many small CPUs which exist within other chips running very specialized code. As profiles mandate these instructions anyway, there's no good reason to complicate the most basic RISC-V possible. RISC-V is the ISA for everything, from the smallest such CPUs to supercomputers.

What MCUs are you thinking of?

To the best of my knowledge (and Google-fu), 26K really isn't a lot of transistors for an embedded MCU - at least not a fully-featured 32-bit one comparable to a minimal RISC-V core. An ARM Cortex M0, which is pretty much the smallest thing out there, is around 10K gates => around 40K transistors. This is also around the same size as a minimal RISC-V core AFAICT.

The ARM core has a shifter, though.

Re: RISC-V Is Sloooow

#168

Post by cmovq »

weebull wrote: post #98
newpavlov wrote: post #44

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.

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…

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.

Re: RISC-V Is Sloooow

#169

Post by snvzz »

wk_end wrote: post #167
snvzz wrote: post #153

Earlier quoted context omitted.

26k is a lot of transistors for an embedded MCU. You'd be excluding many small CPUs which exist within other chips running very specialized code. As profiles mandate these instructions anyway, there's no good reason to complicate the most basic RISC-V possible. RISC-V is the ISA for everything, from the smallest such CPUs to supercomputers.

What MCUs are you thinking of? To the best of my knowledge (and Google-fu), 26K really isn't a lot of transistors for an embedded MCU - at least not a fully-featured 32-bit one comparable to a minimal RISC-V core. An ARM Cortex M0, which is pretty much the smallest thing out there, is around 10K gates => around 40K transistors. This is also around the same size as a minimal RISC-V core AFAICT. The ARM core has a shif…

There's reason RV32E and RV64E, with half the registers, are a thing. RV32I/RV64I isn't small enough.

There are many chips in the market that do embed 8051s for janitorial tasks, because it is small and not legally encumbered. Some chips have several non-exposed tiny embedded CPUs within.

RISC-V is replacing many of these, bringing modern tooling. There's even open source designs like SERV that fit in a corner of an already small FPGA, leaving room for other purposes.

Re: RISC-V Is Sloooow

#170

Post by hun3 »

cmovq wrote: post #168
weebull wrote: post #98

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…

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.
Post reply on HN