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

211–220 of 397 posts

Re: RISC-V Is Sloooow

#211

Post by flowerthoughts »

echoangle wrote: post #154

Is there a simple explanation why RISC-V software has to be built on a RISC-V system? Why is it so hard for compilers to compile for a different architecture? The general structure of the target architecture lives inside the compiler code and isn’t generated by introspecting the current system, right?

Old compilers tended to make it a compile-time switch which backends were included, probably because backends were "huge", so they were left out. (The insn lookup table in GCC took ages to generate and compile.) And of course all development environments running on Windows assumed x86 was the only architecture.

With LLVM existing, cross-compiling is not a problem anymore, but it means you can't run tests without an emulator. So it might just be easier to do it all on the target machine.

Re: RISC-V Is Sloooow

#212

Post by [deleted] »

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.

[deleted]

Re: RISC-V Is Sloooow

#213

Post by panick21_ »

userbinator wrote: post #182
computably wrote: post #176

Earlier quoted context omitted.

> why not just use x86-64? Uh, because you can't? It's not open in any meaningful sense.

The original amd64 came out in 2003. Any patents on the original instruction set have long expired, and even more so for 32-bit x86.

Its not about patents. Believe what you want but there is a reason nobody else is doing x86 or ARM chips unless they are allowed by the owner.

Re: RISC-V Is Sloooow

#214

Post by mort96 »

adastra22 wrote: post #50
newpavlov wrote: post #44

Earlier quoted context omitted.

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.

Do you typically care about portability to the degree that you want the same machine code to execute on both a Linux box and a microcontroller? Why?

Re: RISC-V Is Sloooow

#215

Post by mort96 »

lifis wrote: post #13

Or they could fix cross compilation and then compile it on a normal x86_64 server

Fixing cross compilation is a huge undertaking. So much software needs to be patched to be properly cross-compilable.

Re: RISC-V Is Sloooow

#216

Post by mort96 »

VorpalWay wrote: post #208
IshKebab wrote: post #14

Earlier quoted context omitted.

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.

Yocto manages it thanks to the tireless effort of a community of people maintaining patches and unholy hacks for a ton of software to make it cross compilable. And they have nowhere near the amount of recipes that Fedora has.

Re: RISC-V Is Sloooow

#217

Post by mort96 »

STKFLT wrote: post #55
IshKebab wrote: post #14

Earlier quoted context omitted.

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

Maybe there are issues I'm not aware of but using dockcross has made cross-compilation quite easy in my experience. https://github.com/dockcross/dockcross

How does it handle .so version differences and glibc version differences between the container and the target system?

Re: RISC-V Is Sloooow

#218

Post by veltas »

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.

Relatively new, we're about 16 years down the road.

Re: RISC-V Is Sloooow

#219

Post by pjmlp »

inkyoto wrote: post #206
pjmlp wrote: post #200

Earlier quoted context omitted.

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.

In regards to 68000 I don't remember, only used it during demoscene coding parties when allowed to touch Amiga from my friends.

I have only seen PDP-11 Assembly snippets in UNIX related books, wasn't aware of its alignment requirements.

Re: RISC-V Is Sloooow

#220

Post by utopiah »

FWIW checkout dockcross/linux-riscv32 and dockcross/linux-riscv64 if compilation itself is your problem.

I setup a CopyParty server on a headless RISC-V SBC and was a breeze. Just get the packets, do the thing, move on. Obviously depends on your need but maybe you're not using the right workflow and blame the tools instead.

Post reply on HN