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

131–140 of 397 posts

Re: RISC-V Is Sloooow

#131

Post by Findecanor »

bobmcnamara wrote: post #56
cogman10 wrote: post #38

Earlier quoted context omitted.

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

> The optimizations that'd be applied to ARM and MIPS would be equally applicable to RISC-V. There's no carry bit, and no widening multiply(or MAC)

RISC-V splits widening multiply out into two instructions: one for the high bits and one for the low. Just like 64-bit ARM does.

Integer MAC doesn't exist, and is also hindered by a design decision not to require more than two source operands, so as to allow simple implementations to stay simple. The same reason also prevents RISC-V from having a true conditional move instruction: there is one but the second operand is hard-coded zero.

FMAC exists, but only because it is in the IEEE 754 spec ... and it requires significant op-code space.

Re: RISC-V Is Sloooow

#132

Post by Findecanor »

topspin wrote: post #6
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 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".

Re: RISC-V Is Sloooow

#133

Post by adgjlsfhk1 »

nine_k wrote: post #123
adgjlsfhk1 wrote: post #89

Earlier quoted context omitted.

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

dammmit I meant https://godbolt.org/z/4WxeW58Pc sltu or snez for add/multiply respectively.

Re: RISC-V Is Sloooow

#134

Post by maximilianburke »

cpgxiii wrote: post #57
api wrote: post #12

Earlier quoted context omitted.

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…

I think the story is a bit more complicated. Core succeeded precisely because Intel had both the low-power experience with Pentium-M and the high-power experience with Netburst. The P4 architecture told them a lot about what was and wasn't viable and at what complexity. When you look at the successor generations from Core, what you see are a lot of more complex P4-like features being re-added, but with the benefits o…

And not just any PowerPC architects either, but the people from PA Semi. Motorola couldn't get the speed up and IBM couldn't get the power down.

Re: RISC-V Is Sloooow

#135

Post by kashyapc »

leni536 wrote: post #9

Is cross compilation out of the question?

Near as I know, Fedora prefers native compilation for the builds.

Your question made me look up Arm's history in Fedora and came up on this 2012 LWN thread[1]. There's some discussion against cross-compilation already back then.

[1] https://lwn.net/Articles/487622/

Re: RISC-V Is Sloooow

#136

Post by gt0 »

twoodfin wrote: post #118
gt0 wrote: post #45

Earlier quoted context omitted.

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.

In single-threaded performance? That’s not how I remember it: Sun was pushing parallel throughput over everything else, with designs like the T-Series & Rock.

Perhaps not single thread, but Rock was a dead end a while before Oracle pulled the plug, and Sun/Oracle's core market of course was always servers not workstations. We used Niagara machines at my work around the T2 era, a long time ago, but they were very competitive if you could saturate the cores and had the RAM to back it up.

Re: RISC-V Is Sloooow

#137

Post by kashyapc »

Arm had 40 years to be where it is today. RISC-V is 15 years old. Some more patience is warranted.

Assuming they will keep their word, later this year Tenstorrent is supposed to ship their RVA23-based server development platform[1]. They announced[2] it at the last year's NA RISC-V Summit. Let's see.

The ball is in the court of hardware vendors to cook some high-end silicon.

[1] https://tenstorrent.com/ip/risc-v-cpu

[2] https://static.sched.com/hosted_files/riscvsummit2025/e2/Unl...

Re: RISC-V Is Sloooow

#139

Post by kashyapc »

andrepd wrote: post #33

There's zero mention of hardware specs or cost beyond architecture and core counts... What is the purpose of this post? Anyway, it's hardly surprising that a young ISA with not a 1/1000th of the investment of x86 or ARM has slower chips than them x)

On benchmarks, for more precision details, I recommend the RISC-V Vector (RVV) benchmarks[1], maintained by Olaf Bernsten. He only covers the Vector stuff, but with great depth.

[1] https://camel-cdr.github.io/rvv-bench-results/

Re: RISC-V Is Sloooow

#140

Post by burntoutgray »

adrian_b wrote: post #100
adgjlsfhk1 wrote: post #89

Earlier quoted context omitted.

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

[flagged]

+1 -- misinformation is best corrected quickly. If not, AI will propagate it and many will believe the erroneous information. I guess that would be viral hallucinations.
Post reply on HN