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

71–80 of 397 posts

Re: RISC-V Is Sloooow

#71

Post by adrian_b »

rwmj wrote: post #43
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…

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.

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 hardware is extremely cheap, its cost is absolutely negligible. On the other hand, detecting integer overflow in software is extremely expensive, increasing both the program size and the execution time considerably, because each arithmetic operation must be replaced by multiple operations.

Because of the unacceptable cost, normal RISC-V programs choose to ignore the risk of overflows, which makes them unreliable.

The highest performance implementations of RISC-V from previous years were forced to introduce custom extensions for indexed addressing, but those used inefficient encodings, because something like indexed addressing must be in the base ISA, not in an extension.

Re: RISC-V Is Sloooow

#72

Post by hackyhacky »

adgjlsfhk1 wrote: post #68
adastra22 wrote: post #50

Earlier quoted context omitted.

Also the bit manipulation extension wasn't part of the core. So things like bit rotation is slow for no good reason, if you want portable code. Why? Who knows.

> Also the bit manipulation extension wasn't part of the core. This is primarily because core is primarily a teaching ISA. One of the best parts about RiscV is that you can teach a freshman level architecture class or a senior level chip building project with an ISA that is actually used. Anything powerful to run (a non built from source manually) linux will support a profile that bundles all the commonly needed inst…

> One of the best parts about RiscV is that you can teach a freshman level architecture class or a senior level chip building project with an ISA that is actually used.

Same could be said of MIPS.

My understanding is the RISC-V raison d'etre is rather avoidance of patented/copywritten designs.

Re: RISC-V Is Sloooow

#73

Post by jacquesm »

adgjlsfhk1 wrote: post #68
adastra22 wrote: post #50

Earlier quoted context omitted.

Also the bit manipulation extension wasn't part of the core. So things like bit rotation is slow for no good reason, if you want portable code. Why? Who knows.

> Also the bit manipulation extension wasn't part of the core. This is primarily because core is primarily a teaching ISA. One of the best parts about RiscV is that you can teach a freshman level architecture class or a senior level chip building project with an ISA that is actually used. Anything powerful to run (a non built from source manually) linux will support a profile that bundles all the commonly needed inst…

Bit manipulation instructions are part and parcel of any curriculum that teaches CPU architecture. They are the basic building blocks for many more complex instructions.

https://five-embeddev.com/riscv-bitmanip/1.0.0/bitmanip.html

I can see quite a few items on that list that imnsho should have been included in the core and for the life of me I can't see the rationale behind leaving them out. Even the most basic 8 bit CPU had various shifts and rolls baked in.

Re: RISC-V Is Sloooow

#74

Post by mjmas »

rllj wrote: post #65
fidotron wrote: post #54

Earlier quoted context omitted.

The fact the Hazard3 designer ended up creating an extension to resolve related oddities was kind of astonishing. Why did it fall to them to do it? Impressive that he did, but it shouldn't have been necessary.

Which extension is that?

An extension he calls Xh3bextm. For extracting multiple bits from bitfields.

https://wren.wtf/hazard3/doc/#extension-xh3bextm-section

There are also four other custom extensions implemented.

Re: RISC-V Is Sloooow

#75

Post by rwmj »

jacquesm wrote: post #73
adgjlsfhk1 wrote: post #68

Earlier quoted context omitted.

> Also the bit manipulation extension wasn't part of the core. This is primarily because core is primarily a teaching ISA. One of the best parts about RiscV is that you can teach a freshman level architecture class or a senior level chip building project with an ISA that is actually used. Anything powerful to run (a non built from source manually) linux will support a profile that bundles all the commonly needed inst…

Bit manipulation instructions are part and parcel of any curriculum that teaches CPU architecture. They are the basic building blocks for many more complex instructions. https://five-embeddev.com/riscv-bitmanip/1.0.0/bitmanip.html I can see quite a few items on that list that imnsho should have been included in the core and for the life of me I can't see the rationale behind leaving them out. Even the most basic 8 bi…

This is the reason behind the profiles like RVA23 which include bitmanip, vector and a large number of other extensions. Real chips coming very soon will all be RVA23.

Re: RISC-V Is Sloooow

#78

Post by hackyhacky »

adrian_b wrote: post #71
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.

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.

Re: RISC-V Is Sloooow

#79

Post by leni536 »

STKFLT wrote: post #48
leni536 wrote: post #9

Is cross compilation out of the question?

I'd guess that the issue is running the `%install` and `%check` stages of the .spec file. The Python library rpy (to pull a random example from Marcin's PRs) runs rpy's pytest test suite and had to be modified to avoid running vector tests on RISC-V. Obviously a solvable problem to split build and test but perhaps the time savings aren't worth the complexity. https://src.fedoraproject.org/rpms/rpy/pull-request/4#requ…

Maybe the tests could be run with user-mode qemu instead of the whole thing running under qemu or on RISC-V hardware. Could possibly be more or less seamless with binfmt_misc being set up in the builders.

Re: RISC-V Is Sloooow

#80

Post by classichasclass »

rwmj wrote: post #43
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…

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 capacity or funding), and a cynical take would say they hide them behind NDAs so no one can look behind the curtain.

I know this is a very negative take. I don't try to hide my pro-Power ISA bias, but that doesn't mean I wouldn't like another choice. So far, however, I've been repeatedly disappointed by RISC-V. It's always "five or six years" from getting there.

Post reply on HN