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

321–330 of 397 posts

Re: RISC-V Is Sloooow

#321

Post by saati »

kashyapc wrote: post #137

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…

Aarch64 is just 15 years old, and shares pretty much nothing with 32 bit arms apart from the name.

Re: RISC-V Is Sloooow

#322

Post by snvzz »

Symmetry wrote: post #310
fancyfredbot wrote: post #291

Earlier quoted context omitted.

So it's modular. This is normally considered a good thing. It means you don't have to pay for features you don't need. The ISA is open so there's no greedy corporation trying to upsell you. I mean there's an implementation and die area cost for each extension but it's not being set at an artificial level by a monopolist.

It's a good thing in many cases but not if you're going to be running applications distributed as binaries. Maybe if we go the Gentoo route of everybody always recompiling everything for their own system?

Then you stick to RVA23, which is comparable to ARMv9 and x86-64v4.

Re: RISC-V Is Sloooow

#324

Post by [deleted] »

pjmlp wrote: post #205
burntoutgray wrote: post #141

Earlier quoted context omitted.

ISAs fail to gain traction when the sufficiently smart compilers don't eventuate. The x86-64 is a dog's breakfast of features. But due to its widespread use, compiler writers make the effort to create compilers that optimize for its quirks. Itanium hardware designers were expecting the compiler writers to cater for its unique design. Intel is a semi company. As good as some of their compilers are, internally they inv…

I am a firm believer that if AMD wasn't in the position to be able to come up with AMD64 architecture, eventually those Itanium issues would have been sorted out, Windows XP was already there and there was no other way for 64 bit going forward.

[deleted]

Re: RISC-V Is Sloooow

#325

Post by bigstrat2003 »

burntoutgray wrote: post #140
adrian_b wrote: post #100

Earlier quoted context omitted.

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

One can quickly correct misinformation without being rude. It's not hard, and does not lessen the impact of the correction to do so. There's no reason to tolerate the kind of rudeness the parent post exhibits.

Re: RISC-V Is Sloooow

#326

Post by topspin »

imtringued wrote: post #250
topspin wrote: post #172

Earlier quoted context omitted.

I can't know what Ascalon will actually be, but back in April/May 2025 there were actual performance numbers presented by Tenstorrent, and I analyzed what was shown. I concluded that Ascalon would be the x86_64 equivalent of an i5-9600K. That's useable for many applications, but it's not going to change the world. A lot of "micro PCs" with low power CPUs are well past that now. If that's what Ascalon turns out to be,…

I don't know what bubble you are living in, but the i5-9600K is many steps up beyond "SBC class". The Raspberry Pi 5 results on Geekbench 6 are all over the place. A score between 500 to 900 in single core and a 2000 multi core score. Radxa 4 is an SBC based around the N100 and it basically gets the same or slightly higher performance as the Raspberry Pi 5. Meanwhile the i5-9600K gets a score of 1677 in single core,…

"I don't know what bubble you are living in"

My bubble includes a number of SBCs and embedded boards from Advantech, frequently using Ryzen embedded (V1000 class) CPUs.

SBC is too vague I suppose. Past the Raspberry Pi form factor SBC class, there are many* SBC vendors with Core i5-1340P and similar CPUs today. That's a 2023 device, and just past a 2018 i5-9600K, aligning well with what I claimed.

In 2025+, such a CPU is not a desktop class device, and is sufficient only in low cost laptops (but in much lower power form.) A MacBook Neo A18, for example, is considerably better than a i5-9600K.

It would be great if Tentorrent actually yields such a product, and if, based on later performance projections that appeared in late 2025, Ascalon is actually faster, but, as I said, the world will not change much. RISC-V developers will appreciate compiling like it's 2019, but that's as far as it will go.

* LattePanda Sigma, ASROCK NUC, DFROBOT, Premio and many NAS and industrial devices.

Re: RISC-V Is Sloooow

#327

Post by adgjlsfhk1 »

kbolino wrote: post #320
adgjlsfhk1 wrote: post #133

Earlier quoted context omitted.

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

This result is misleading. First, the code claims to be returning "unsigned long" from each of these functions, but the value will only ever be 0 or 1 (see [1]). The code is actually throwing away the result and just returning whether overflow occurred. If we take unsigned long *c as another argument to the function, so that we actually keep the result, we end up having to issue an extra instruction for multiplicatio…

That's fair. The good news is that for signed overflow, you can claw back to the cost of unsigned overflow if you know the sign of either argument (which is fairly common).

Re: RISC-V Is Sloooow

#328

Post by kbolino »

adgjlsfhk1 wrote: post #327
kbolino wrote: post #320

Earlier quoted context omitted.

This result is misleading. First, the code claims to be returning "unsigned long" from each of these functions, but the value will only ever be 0 or 1 (see [1]). The code is actually throwing away the result and just returning whether overflow occurred. If we take unsigned long *c as another argument to the function, so that we actually keep the result, we end up having to issue an extra instruction for multiplicatio…

That's fair. The good news is that for signed overflow, you can claw back to the cost of unsigned overflow if you know the sign of either argument (which is fairly common).

Yeah, it's not the end of the world, and as others mentioned, a good implementation can recognize the instruction pattern and optimize for it.

It's just a bizarre design choice. I understand wanting to get rid of condition flags, but not replacing them with nothing at all.

EDIT: It seems the same choice was made by MIPS, which is a clear inspiration for RISC-V.

Re: RISC-V Is Sloooow

#329

Post by 0verkilled »

Unrelated to the post's point but: Why does x86 build faster than x86_64? Presumably they used the same exact hardware, or at least the exact same number of cores and memory, yet the build time is more than 10% faster in x86. Is there some sort of overhead for x86_64 that I'm not seeing?

Re: RISC-V Is Sloooow

#330

Post by adgjlsfhk1 »

kbolino wrote: post #328
adgjlsfhk1 wrote: post #327

Earlier quoted context omitted.

That's fair. The good news is that for signed overflow, you can claw back to the cost of unsigned overflow if you know the sign of either argument (which is fairly common).

Yeah, it's not the end of the world, and as others mentioned, a good implementation can recognize the instruction pattern and optimize for it. It's just a bizarre design choice. I understand wanting to get rid of condition flags, but not replacing them with nothing at all. EDIT: It seems the same choice was made by MIPS, which is a clear inspiration for RISC-V.

The argument is that there are actually 3 distinct forms of replacement:

1. 64 bit signed math is a lot less overflow vulnerable than the 16/32 bit math that was extremely common 20 years ago

2. For the BigInt use-case, the Riscv design is pretty sensible since you want the top bits, not just presence of overflow

3. You can do integer operations on the FPU (using the inexact flag for detecting if rounding occurred).

4. Adding overflow detecting instructions can easily be done in an extension in the future if desired.

Post reply on HN