Live data from Hacker News

RISC-V Is Sloooow

marcin.juszkiewicz.com.pl

61–70 of 397 posts

Re: RISC-V Is Sloooow

#61
Are you sure you are comparing apples with apples here?

The fact that i686 is 14% faster than x86_64 is a little suspicious, because usually the same software runs _faster_ on x86_64 (despite the increased memory use) thanks to a larger register set, an optimized ABI, and more vector instructions.

Of course, if you are compiling an i686 binary on i686, and an x86_64 binary on x86_64, then the compilers aren't really doing the same work, since their output is different. I'm not a compiler expert, but I could imagine that compiling x86_64 binaries is intrinsically slower than for i686 for a variety of reasons. For example, x86_64 is mostly a superset of i686, so a compiler has way more instructions to consider, including potential optimizations using e.g. SIMD instructions that don't exist on i686 at all. Or a compiler might assume a larger instruction cache size, by default, and do more unrolling or inlining when compiling for x86_64. And so on.

In that case, compiling on x86_64 is slower not because the hardware is bad but because the compiler does more work. Perhaps something similar is happening on RISC-V.

Re: RISC-V Is Sloooow

#63
post #10
post #4

Earlier quoted context omitted.

I did read it. A Banana Pi is not the fastest developer platform. The title is misleading. BTW, it's quite impressive how the s390x is so fast per core compared to the others. I mean, of course it's fast - we all knew that. And don't let IBM legal see this can be considered a published benchmark, because they are very shy about s390x performance numbers.

I was really surprised by the s390x performance, but I also don't really understand why there are build time listed by architecture, not the actual processors.

i686 builds even faster

Re: RISC-V Is Sloooow

#64

Earlier quoted context omitted.

> AND the software with no architecture-specific optimisations The optimizations that'd be applied to ARM and MIPS would be equally applicable to RISC-V. I do not believe this is a lack of software optimization issue. We are well past the days where hand written assembly gives much benefit, and modern compilers like gcc and llvm do nearly identical work right up until it comes to instruction emissions (including dete…

[flagged]

While true, it's typically not going to be impactful on system performance.

There's a reason, for example, why the linux distros all target a generic x86 architecture rather than a specific architecture.

Re: RISC-V Is Sloooow

#65

Earlier quoted context omitted.

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.

The fact the Hazard3 designer ended up creating an extension to resolve related oddities was kind of astonishing. Why did it fall to them to do it? Impressive that he did, but it shouldn't have been necessary.

Which extension is that?

Re: RISC-V Is Sloooow

#66
post #43

Earlier quoted context omitted.

RISC-V doesn't have the pitfalls of Sparc (register windows, branch delay slots), largely because we learned from that. It's in fact a very "boring" architecture. There's no one that expects it'll be hard to optimize for. There are at least 2 designs that have taped out in small runs and have high end performance.

> RISC-V doesn't have the pitfalls of Sparc (register windows, branch delay slots), You're saying ISA design does have implementation performance implications then? ;) > There's no one that expects it'll be hard to optimize for [Raises hand] > There are at least 2 designs that have taped out in small runs and have high end performance. Are these public? Edit: I should add, I'm well aware of the cultural mismatch betw…

The 2 designs I'm thinking of are (tiresomely) under NDA, although I'm sure others will be able to say what they are. Last November I had a sample of one of them in my hand and played with the silicon at their labs, running a bunch of AI workloads. They didn't let me take notes or photographs.

> There's no one that expects it'll be hard to optimize for

No one who is an expert in the field, and we (at Red Hat) talk to them routinely.

Re: RISC-V Is Sloooow

#67
post #18
post #7

Earlier quoted context omitted.

> At this point the most likely place for fast RISC-V to appear is China. Or we just adopt Loongson.

TBH I still don't really get how it's different from MIPS. As far as I can tell... Loongson seems to be really just MIPS, while LoongArch is MIPS with some extra instructions.

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

Re: RISC-V Is Sloooow

#68

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.

> Also the bit manipulation extension wasn't part of the core.

This is primarily because core is primarily a teaching ISA. One of the best parts about RiscV is that you can teach a freshman level architecture class or a senior level chip building project with an ISA that is actually used. Anything powerful to run (a non built from source manually) linux will support a profile that bundles all the commonly needed instructions to be fast.

Re: RISC-V Is Sloooow

#69
post #10
post #4

Earlier quoted context omitted.

I did read it. A Banana Pi is not the fastest developer platform. The title is misleading. BTW, it's quite impressive how the s390x is so fast per core compared to the others. I mean, of course it's fast - we all knew that. And don't let IBM legal see this can be considered a published benchmark, because they are very shy about s390x performance numbers.

I was really surprised by the s390x performance, but I also don't really understand why there are build time listed by architecture, not the actual processors.

What's fast on Z platforms is typically IO rather than raw CPU - the platform can push a lot of parallell data. This is typically the bottleneck when compiling.

The cores are in my experience moderately fast at most. Note that there are a lot of licencing options and I think some are speed-capped - but I don't think that applies to IFL - a standard CPU licence-restricted to only run linux.

Re: RISC-V Is Sloooow

#70

Earlier quoted context omitted.

[flagged]

While true, it's typically not going to be impactful on system performance. There's a reason, for example, why the linux distros all target a generic x86 architecture rather than a specific architecture.

Not all. CachyOS has specific builds for v3, v4, and AMD Zen4/5: https://wiki.cachyos.org/features/optimized_repos/
Post reply on HN