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

201–210 of 397 posts

Re: RISC-V Is Sloooow

#201

Post by menaerus »

LeFantome wrote: post #104
menaerus wrote: post #8

Earlier quoted context omitted.

Which risc-v implementation is considered fast?

> Which risc-v implementation is considered fast? SpacemiT K3 is 2010 Macbook performance single-core, 2019 Macbook Air multi-core, and better than M4 Apple Silicon for AI. So I guess it depends on what you are going to do with it.

M4 is 38 TOPS at INT8 precision whereas SpacemiT K3 is 60 TOPS at INT4 precision so at best they would be equal in "AI" performance but they are not because the rest of the K3 chip is much less capable than M4 (as I would expect).

E.g. M4 total system memory bandwidth is 120GB/s whereas K4 is 51GB/s, single core memory bandwidth is 100-120GB/s vs ~30GB/s. M4 has 10 CPU cores and neural engine with 16 cores whereas K3 has 8 CPU cores and 8 "AI" cores, K3 clock frequency is almost half the clock frequency in M4 etc. etc.

But anyway thanks for sharing, always good to learn about new hardware.

Re: RISC-V Is Sloooow

#202

Post by kldg »

cmovq wrote: post #168
weebull wrote: post #98

Earlier quoted context omitted.

All of those things are solved with modern extensions. It's like comparing pre-MMX x86 code with modern x86. Misaligned loads and stores are Zicclsm, bit manipulation is Zb[abcs], atomic memory operations are made mandatory in Ziccamoa. All of these extensions are mandatory in the RVA22 and RVA23 profiles and so will be implemented on any up to date RISC-V core. It's definitely worth setting your compiler target appr…

But RISC-V is a _new_ ISA. Why did we start out with the wrong design that now needs a bunch of extensions? RISC-V should have taken the learnings from x86 and ARM but instead they seem to be committing the same mistakes.

I was a bit shocked by headline, given how poorly ARM and x86 compares to RISC-V in speed, cost, and efficiency ... in the MCU space where I near-exclusively live and where RISC-V has near-exclusively lived up until quite recently. RISC-V has been great for RTOS systems and Espressif in particular has pushed MCUs up to a new level where it's become viable to run a designed-from-scratch web server (you better believe we're using vector graphics) on a $5 board that sits on your thumb, but using RISC-V in SBCs and beyond as the primary CPU is a very different ballgame.

Re: RISC-V Is Sloooow

#205

Post by pjmlp »

burntoutgray wrote: post #141
adrian_b wrote: post #121

Earlier quoted context omitted.

I would not call PA-RISC boring. Already at launch there was no doubt that it is a better ISA than SPARC or MIPS, and later it was improved. At the time when PA-RISC 2.0 was replaced by Itanium it was not at all clear which of the 2 ISAs is better. The later failures to design high-performance Itanium CPUs make plausible that if HP would have kept PA-RISC 2.0 they might have had more competitive CPUs than with Itaniu…

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.

Re: RISC-V Is Sloooow

#206

Post by inkyoto »

pjmlp wrote: post #200
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.

On modern CPUs, it used not to be something to care about in the past across 8, 16, 32 bit generations, outside RISC.

PDP-11, m68k – to name a few, did not allow misaligned access to anything that was not a byte.

Neither are RISC nor modern.

Re: RISC-V Is Sloooow

#207

Post by BoredomIsFun »

LeFantome wrote: post #192
sidewndr46 wrote: post #165

Earlier quoted context omitted.

You're correct but I guess my thoughts are if we're going to wind up with a mess of extensions, why not just use x86-64?

First, x86-64 also has “extensions” such as avx, avx2, and avx512. Not all “x86-64” CPUs support the same ones. And you get things like svm on AMD and avx on Intel. Remember 3DNow? X86-64 also has “profiles” which tell you what extensions should be available. There is x86-64v1 and x86-64v4 with v2 and v3 in the middle. RVA23 offers a very similar feature-set to x86-64v4. You do not end up with a mess of extensions. Y…

1. Yes, but most of the code would run on anything older than 2007. 20 years of stable ISA.

2. Also, fundamentally all modern CPUs are still 64-bit version of 80386. MMU, protection, low level details are all same.

Re: RISC-V Is Sloooow

#208

Post by VorpalWay »

IshKebab wrote: post #14
leni536 wrote: post #9

Is cross compilation out of the question?

It's usually an enormous pain to set up. QEMU is probably the best option.

Yocto, which we use at work, manages it just fine to build a whole embedded Linux distro. So I don't see why Fedora couldn't make it work if they wanted. You could even scp over the test suites to run that on native systems if you wanted.

Re: RISC-V Is Sloooow

#209

Post by bonzini »

mananaysiempre wrote: post #122
bonzini wrote: post #67

Earlier quoted context omitted.

LoongArch is, on a first approximation, an almost RISC-V user space instruction set together with MIPS-like privileged instructions and registers.

Wait, this is a modern-ish ISA with a software-managed TLB, I didn’t realize that! The manual seems a bit unhappy about that part though: > In the current version of this architecture specification, TLB refill and consistent maintenance between TLB and page tables are still [sic] all led by software. https://loongson.github.io/LoongArch-Documentation/LoongArch...

I think they have already added hardware page table walks.

https://lwn.net/Articles/932048/

Re: RISC-V Is Sloooow

#210

Post by IshKebab »

newpavlov wrote: post #114
weebull wrote: post #98

Earlier quoted context omitted.

All of those things are solved with modern extensions. It's like comparing pre-MMX x86 code with modern x86. Misaligned loads and stores are Zicclsm, bit manipulation is Zb[abcs], atomic memory operations are made mandatory in Ziccamoa. All of these extensions are mandatory in the RVA22 and RVA23 profiles and so will be implemented on any up to date RISC-V core. It's definitely worth setting your compiler target appr…

>Misaligned loads and stores are Zicclsm Nope. See https://github.com/llvm/llvm-project/issues/110454 which was linked in the first issue. The spec authors have managed to made a mess even here. Now they want to introduce yet another (sic!) extension Oilsm... It maaaaaay become part of RVA30, so in the best case scenario it will be decades before we will be able to rely on it widely (especially considering that RVA23…

I think having separate unaligned load/store instructions would be a much worse design, not least because they use a lot of the opcode space. I don't understand why you don't just have an option to not generate misaligned loads for people that happen to be running on CPUs where it's really slow. You don't need to wait for a profile for that.

As for `seed`, if you're running on a microcontroller you can just look up the data sheet to see if it's seed entropy is sufficient. By the time you get to CPUs where portable code is important a CSPRNG is probably fine.

I agree about page size though. Svnapot seems overly complicated and gives only a fraction of the advantages of actually bigger pages.

Post reply on HN