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

41–50 of 397 posts

Re: RISC-V Is Sloooow

#41

Post by cestith »

Aurornis wrote: post #36
rbanffy wrote: post #4

Earlier quoted context omitted.

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.

> A Banana Pi is not the fastest developer platform. What is the current fastest platform that isn’t exorbitantly expensive? Not upcoming releases, but something I can actually buy. I check in every 3-6 months but the situation hasn’t changed significantly yet.

What is the current fastest ppc64le implementation that isn’t exorbitantly expensive? How about the s390x?

Re: RISC-V Is Sloooow

#42

Post by jauntywundrkind »

api wrote: post #12
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…

A pattern I've noticed for a very long time: A lot of times the path to the highest performing CPU seems to be to optimize for power first , then speed, then repeat. That's because power and heat are a major design constraint that limits speed. I first noticed this way back with the Pentium 4 "Netburst" architecture vs. the smaller x86 cores that became the ancestor of the Core architecture. Intel eventually ran into…

Parallels to code design, where optimizing data or code size can end up having fantastic performance benefits (sometimes).

Re: RISC-V Is Sloooow

#43

Post by rwmj »

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…

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.

Re: RISC-V Is Sloooow

#44

Post by newpavlov »

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…

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.

Re: RISC-V Is Sloooow

#45

Post by gt0 »

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…

I don't think anybody suggests Oracle couldn't make faster SPARC processors, it's just that development of SPARC ended almost 10 years ago. At the time SPARC was abandoned, it was very competitive.

Re: RISC-V Is Sloooow

#46

Post by cptskippy »

api wrote: post #12
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…

A pattern I've noticed for a very long time: A lot of times the path to the highest performing CPU seems to be to optimize for power first , then speed, then repeat. That's because power and heat are a major design constraint that limits speed. I first noticed this way back with the Pentium 4 "Netburst" architecture vs. the smaller x86 cores that became the ancestor of the Core architecture. Intel eventually ran into…

Core evolved from the Banis (Centrino) CPU core which was based on P3, not P4. Banias used the front-side bus from P4 but not the cores.

Banias was hyper optimized for power, the mantra was to get done quickly and go to sleep to save power. Somewhere along the line someone said "hey what happens if we don't go to sleep?" and Core was born.

Re: RISC-V Is Sloooow

#47

Post by hrmtst93837 »

cogman10 wrote: post #38
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…

> AND the software with no architecture-specific optimisations The optimizations that'd be applied to ARM and MIPS would be equally applicable to RISC-V. I do not believe this is a lack of software optimization issue. We are well past the days where hand written assembly gives much benefit, and modern compilers like gcc and llvm do nearly identical work right up until it comes to instruction emissions (including dete…

[flagged]

Re: RISC-V Is Sloooow

#48

Post by STKFLT »

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

Re: RISC-V Is Sloooow

#49

Post by fidotron »

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 doesn't have the pitfalls of Sparc (register windows, branch delay slots),

You're saying ISA design does have implementation performance implications then? ;)

> There's no one that expects it'll be hard to optimize for

[Raises hand]

> There are at least 2 designs that have taped out in small runs and have high end performance.

Are these public?

Edit: I should add, I'm well aware of the cultural mismatch between HN and the semi industry, and have been caught in it more than a few times, but I also know the semi industry well enough to not trust anything they say. (Everything from well meaning but optimistic through to outright malicious depending on the company).

Re: RISC-V Is Sloooow

#50

Post by adastra22 »

newpavlov wrote: post #44
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…

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.

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