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

281–290 of 397 posts

Re: RISC-V Is Sloooow

#281

Post by aa-jv »

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?

Native builds are always a safer/more reliable path to take than cross-compiling, which usually requires solid native builds to be operational before the cross environment can be reliably trusted.

Its a bootstrapping chain of priority. Once a native build regime is set in stone, cross compiling harnesses can be built to exploit the beachhead.

I have saved many a failing projects budget and deadline by just putting the compiler onboard and obviating the hacky scaffolding usually required for reliable cross compiling at the beginning stages of a new architecture project, and I suspect this is the case here too ..

Re: RISC-V Is Sloooow

#282

Post by titzer »

> ... I can build the “llvm15” package in about 4 hours. Compare that to 10.5 hours on a Banana Pi BPI-F3 builder (it may be quicker on a P550 one).

That's....slow. What a huge pile of bloat.

Re: RISC-V Is Sloooow

#283

Post by blacklion »

wolvoleo wrote: post #177
cmovq wrote: post #168

Earlier quoted context omitted.

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.

It is a reduced instruction set computing isa of course. It shouldn't really have instructions for every edge case. I only use it for microcontrollers and it's really nice there. But yeah I can imagine it doesn't perform well on bigger stuff. The idea of risc was to put the intelligence in the compiler though, not the silicon.

> The idea of risc was to put the intelligence in the compiler though, not the silicon.

Itanium did this mistake. Sure, compilers are much better now, but still dynamic scheduling beats static one for real-world tasks. You can (almost perfectly) statically schedule matrix multiplication but not UI or 3D game.

Even GPUs have some amount of dynamic scheduling now.

Re: RISC-V Is Sloooow

#284

Post by brohee »

hackyhacky wrote: post #78
adrian_b wrote: post #71

Earlier quoted context omitted.

RISC-V does not have the pitfalls of experimental ISAs from 45 years ago, but it has other pitfalls that have not existed in almost any ISA since the first vacuum-tube computers, like the lack of means for integer overflow detection and the lack of indexed addressing. Especially the lack of integer overflow detection is a choice of great stupidity, for which there exists no excuse. Detecting integer overflow in hardw…

> On the other hand, detecting integer overflow in software is extremely expensive, increasing both the program size and the execution time considerably, Most languages don't care about integer overflow. Your typical C program will happily wrap around. If I really want to detect overflow, I can do this: add t0, a0, a1 blt t0, a0, overflow Which is one more instruction, which is not great, not terrible.

It's one more instruction only if you don't fuse those instructions in the decoder stage, but as the pattern is the one expected to be generated by compilers, implementations that care about performance are expected to fuse them.

Re: RISC-V Is Sloooow

#285

Post by [deleted] »

inkyoto wrote: post #196
userbinator wrote: post #183

Earlier quoted context omitted.

I don't know if that construction might allow for a more efficient transistor count and it's totally impractical - 1KHz clock speed, 1-bit ALU, etc. - for almost any purpose, but it is technically a RISC-V implementation significantly smaller than 26K That sounds like a microcoded RISC-V implementation, which can really be done for any ISA at the extreme expense of speed.

If I'm not mistaken, microcode is a thing at least on Intel CPU's, and that is how they patched Spectre, Meltdown and other vulnerabilities – Intel released a microcode update that BIOS applies at the cold start and hot patches the CPU. Maybe other CPU's have it as well, though I do not have enough information on that.

[deleted]

Re: RISC-V Is Sloooow

#286

Post by MarsIronPI »

panick21_ wrote: post #261
dbdr wrote: post #244

Earlier quoted context omitted.

You're probably right. It would be helpful to say what the reason is, if it's not patents.

I'm not a lawyer but I would assume its copyright. Kind of like API in software. In software somehow this does not apply most of the time. But it seems in hardware this is very real. But I would appreciate a lawyer jumping in. I know for example that Berkley when thinking pre-RISC-V that they had a deal with Intel about using x86-64 for research. But they were not able to share the designs.

I don't know why there aren't independent X86-64 manufacturers. Patents on the extensions maybe? But as I understand copyright, APIs can't be copyrighted so it's not that.

Re: RISC-V Is Sloooow

#287

Post by sidewndr46 »

BoredomIsFun wrote: post #207
LeFantome wrote: post #192

Earlier quoted context omitted.

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.

This isn't really accurate, lots of commercial software is now compiled for newer x86 64 extensions.

If you're using OSS it doesn't really matter as you can compile it for whatever you want.

Re: RISC-V Is Sloooow

#288

Post by haerwu »

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?

Cross compilation of entire distributions requires such distributions to be prepated for it. Which is not a case when you use OpenEmbedded/Yocto or Buildroot to build it. But it gets complicated with distributions which are built natively.

Fedora does not have a way to cross compile packages. The only cross compiler available in repositories is bare-metal one. You can use it to build firmware (EDK2, U-Boot) or Linux kernel. But nothing more.

Then there is the other problem: testing. What is a point of successful build if it does not work on target systems? Part of each Fedora build is running testsuite (if packaged software has any). You should not run it in QEMU so each cross-build would need to connect to target system, upload build artifacts and run tests. Overcomplicated.

Native builds allows to test is distribution ready for any kind of use. I use AArch64 desktop daily for almost a year now. But it is not "4core/16GB ram SBC" but rather "server-as-a-desktop" kind (80 cores, 128 GB ram, plenty of PCI-Express lanes). And I build software on, write blog posts, watch movies etc. And can emulate other Fedora architectures to do test builds.

Hardware architecture slow today, can be fast in the future. In 2013 building Qt4 for Fedora/AArch64 took days (we used software emulators). Now it takes 18 minutes.

Re: RISC-V Is Sloooow

#289

Post by sidewndr46 »

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…

It's actually worst because intel is introducing APX now as well.

Re: RISC-V Is Sloooow

#290

Post by galangalalgol »

kldg wrote: post #202
cmovq wrote: post #168

Earlier quoted context omitted.

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…

I have a couple c3 I was playing with. Are you talking about the P4 or C6? Aren't their xtensa offerings still faster?
Post reply on HN