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

391–397 of 397 posts

Re: RISC-V Is Sloooow

#391

Post by camel-cdr »

purplesyringa wrote: post #355
camel-cdr wrote: post #339

Earlier quoted context omitted.

OK, look. Since my previous attempt to measure the impact of trap on signed overflow didn't seem to have moved your position one bit, I thought I'd give it a go in the most representable way I could think of: I build the same version of clang on a x86, aarch64 and RISC-V system using clang. Then I build another version with the `-ftrapv` flag enabled and compared the compiletimes of compiling programs using these cla…

I suspect that LLVM is optimized for compiling with `-ftrapv`, perhaps for cheap sanitizing or maybe just due to design decisions like using unsigned integers everywhere (please correct me if I'm wrong). I'm personally interested in how RISC-V behaves on computational tasks where computing carry is a known bottleneck, like long addition. Maybe looking at libgmp could be interesting, though I suspect absolute numbers…

LLVM mostly uses size_t like most C/C++ programs, which either use size_t or int for everything, both of which are handled well by RISC-V.

> Maybe looking at libgmp could be interesting, though I suspect absolute numbers will not be meaningful, and there's no baseline to compare them to.

Realistically, nobody cares about BigInt addition performance, considering there is no GMP implementarion using SIMD, or even any using dependency breaking to get beyond 64-bit per cycle.

I whipped up a quick AVX-512 implementation that was 2x faster than libgmp on Zen4 (which has 256-bit SIMD ALUs). On RISC-V you'd just use RVV to do BigInt stuff.

Re: RISC-V Is Sloooow

#392

Post by wren6991 »

mjmas wrote: post #74
rllj wrote: post #65

Earlier quoted context omitted.

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.

This extension wasn't strictly necessary but it makes decode of Arm instructions faster in the bootrom's Arm emulator.

Re: RISC-V Is Sloooow

#393

Post by wren6991 »

twoodfin wrote: post #164
ori_b wrote: post #150

Earlier quoted context omitted.

It's 4k on x86 as well. Doesn't seem to hurt so bad -- at least, not enough to explain the risc-v performance gap.

Hmm? x86 has supported much larger “huge” page sizes for ages.

Yep, RISC-V also has these megapages. 4k is the last-level page size. You get larger pages (4M on 32-bit and 2M/1G on 64-bit) by terminating the walk at higher levels of the page table.

Re: RISC-V Is Sloooow

#394

Post by wren6991 »

fredoralive wrote: post #224
tosti wrote: post #195

Earlier quoted context omitted.

Regarding misaligned reads, IIRC only x86 hides non-aligned memory access. It's still slower than aligned reads. Other processors just fault, so it would make sense to do the same on riscv. The problem is decades of software being written on a chip that from the outside appears not to care.

ARM Cortex-A cores also allow unaligned access (MCU cores don't though, and older ARM is weird). There's perhaps a hint if the two most popular CPU architectures have ended up in the forgiving approach to unaligned access, rather than the penalising approach of raising an interrupt.

> MCU cores don't though

v6-M doesn't (e.g. Cortex-M0+). v7-M and v8-M do allow unaligned access on Normal memory but not on Device memory.

Re: RISC-V Is Sloooow

#395

Post by saghm »

Levitating wrote: post #242
saghm wrote: post #147

If I'm reading their chart right, they have barely half as much memory for their RISC-V machine compared to any of the others? I don't know enough to know whether it's actually bottlenecked by memory, but it's a bit odd to claim it's slower, give those numbers, and not say anything about it. I'd hope they ruled that out as the source of the discrepancy, but it's hard to tell without confirmation.

I think it's mentioned clearly in the article. > RISC-V builders have four or eight cores with 8, 16 or 32 GB of RAM (depending on a board) > The UltraRISC UR-DP1000 SoC, present on the Milk-V Titan motherboard should improve situation a bit (and can have 64 GB ram). RISC-V SOCs just typically don't support much ram. With the exception of the SG2042 which can take 128GB, but it's expensive, buggy and now old. So I am…

That sounds a lot less "RISC-V is slow" and more like "the most money I'm willing to spend on a RISC-V machine is low, but the more powerful ones may or not be as slow". I guess that doesn't make a particularly compelling headline.

Re: RISC-V Is Sloooow

#396

Post by purplesyringa »

camel-cdr wrote: post #391
purplesyringa wrote: post #355

Earlier quoted context omitted.

I suspect that LLVM is optimized for compiling with `-ftrapv`, perhaps for cheap sanitizing or maybe just due to design decisions like using unsigned integers everywhere (please correct me if I'm wrong). I'm personally interested in how RISC-V behaves on computational tasks where computing carry is a known bottleneck, like long addition. Maybe looking at libgmp could be interesting, though I suspect absolute numbers…

LLVM mostly uses size_t like most C/C++ programs, which either use size_t or int for everything, both of which are handled well by RISC-V. > Maybe looking at libgmp could be interesting, though I suspect absolute numbers will not be meaningful, and there's no baseline to compare them to. Realistically, nobody cares about BigInt addition performance, considering there is no GMP implementarion using SIMD, or even any u…

"nobody cares about BigInt addition performance" is an odd claim to make when half of the world's cryptography is based on ECC.

Re: RISC-V Is Sloooow

#397

Post by sidewndr46 »

panick21_ wrote: post #359
userbinator wrote: post #346

Earlier quoted context omitted.

and is not being copied Are you sure, especially considering China? I doubt there is any legal barrier, because there are a few existing projects with x86 cores on an FPGA, as well as some SoCs. Here's a 486: https://opencores.org/projects/ao486

Ok if China is doing something only for China market that tells you something. As for opencores, yes you can design them, but do any companies making commercial products sell them?

I'm reasonably certain at least one Chinese fab has a license for some of AMDs older product lines
Post reply on HN