Discussion

Marcin Juszkiewicz

rbanffy: Don't blame the ISA - blame the silicon implementations AND the software with no architecture-specific optimisations.RISC-V will get there, eventually.I remember that ARM started as a speed demon with conscious power consumption, then was surpassed by x86s and PPCs on desktops and moved to embedded, where it shone by being very frugal with power, only to now be leaving the embedded space with implementations optimised for speed more than power.

dmitrygr: IF you care to read the article, they indeed do not blame the architecture but the available silicon implementations.

tromp: But they didn't reflect that in a title like "current RISC-V silicon Is Sloooow" ...

rbanffy: I did read it. A Banana Pi is not the fastest developer platform. The title is misleading.

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

api: A pattern I've noticed for a very long time:A lot of times the path to the highest performing CPU seems to be to optimize for power first, then speed, then repeat. That's because power and heat are a major design constraint that limits speed.I first noticed this way back with the Pentium 4 "Netburst" architecture vs. the smaller x86 cores that became the ancestor of the Core architecture. Intel eventually ran into a wall with P4 and then branched high performance cores off those lower-power ones and that's what gave us the venerable Core architecture that made Intel the dominant CPU maker for over a decade.ARM's history is another example.

spiderice: Then how do you justify the title?

gt0: 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.

rbalint: If the builds are slow, build accelerators can help a lot. Ccache would work for sure and there is also firebuild, that can accelerate the linker phase and many other tools in builds.

IshKebab: Yeah it's a few years behind ARM, but not that many. Imagine trying to compile this on ARM 10 years ago. It would be similarly painful.

Levitating: This is why felix has been building the risc-v archlinux repositories[1] using the Milk-V Pioneer.I think the ban of SOPHGO is part to blame for the slow development.[2] They had the most performant and interesting SOCs. I had a bunch of pre-orders for the Milk-V Oasis before it was cancelled. It was supposed to come out a while ago, using the SG2380, supposedly much more performant than the Milk-V Titan mentioned in the article (which still isn't out).It was also SOPHGO's SOCs that powered the crazy cheap/performant/versatile Milk-V DUO boards. They have the ability to switch ARM/RISC-V architecture.[1]: https://archriscv.felixc.at/[2]: https://www.tomshardware.com/tech-industry/artificial-intell...

Joel_Mckay: Any new hardware lags in compiler optimizations.i. llvm presentation can thrash caches if setup wrong (given the plethora of RISC-V fragmented versions, most compilers won't cover every vanity silicon.)ii. gcc is also "slow" in general, but is predictable/reliableiii. emulation is always slower than kvm in qemuIt may seem silly, but I'd try a gcc build with -O0 flag, and a toy unit test with -S to see if the ASM is actually foobar. One may have to brute force the optimizer flags to narrow your search. Best regards =3

rbanffy: Probably because that's just the infrastructure they have.

leni536: Is cross compilation out of the question?

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

sofixa: Depends on the language, it's pretty trivial with Go.

menaerus: Which risc-v implementation is considered fast?

patchnull: Nothing shipping today is really competitive with modern ARM or x86. The SiFive P870 and Tenstorrent Ascalon (Jim Keller's team) are the most anticipated high-performance designs, but neither is widely available. What you can actually buy today tops out around Cortex-A76 class single-thread performance at best, which is roughly where ARM was five or six years ago.

menaerus: I remember taking down some notes wrt SiFive P870 specs, comparing them to x86_64, and reaching the same conclusion. Narrower core width (4-wide vs 8-wide), lower clock frequency (peaks at 3GHz) and no turbo (?), limited support for vector execution (128-bit vs 512-bit), limited L1 bandwidth (1x 128-bit load/cycle?), limited FP compute (2x 128-bit vs 2x 512-bit), load queue is also inconveniently small with 48 entries (affecting already limited load bandwidth), unclear system memory bandwidth and how it scales wrt the number of cores (L3 contention) although for the latter they seem to use what AMD is doing (exclusive L3 cache per chiplet).

jnovek: I don’t have a micro architecture background so I apologize if this is obvious — What do power and speed mean in this context?

McP: Power - how many Watts does it need? Speed - how quickly can it perform operations?

hackerInnen: This. While I doubt that there will be a good (whatever that means) desktop risc-v CPU anytime soon, I do think that it will eventually catch up in embedded systems and special applications. Maybe even high core count servers.It just takes time, people who believe in it and tons of money. Will see where the journey goes, but I am a big risc-v believer

fidotron: > RISC-V will get there, eventually.Not trolling: I legitimately don't see why this is assumed to be true. It is one of those things that is true only once it has been achieved. Otherwise we would be able to create super high performance Sparc or SuperH processors, and we don't.As you note, Arm once was fast, then slow, then fast. RISC-V has never actually been fast. It has enabled surprisingly good implementations by small numbers of people, but competing at the high end (mobile, desktop or server) it is not.

topspin: I keep checking in on Tenstorrent every few months thinking Keller is going to rock our world... losing hope.At this point the most likely place for truly competitive RISC-V to appear is China.

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

balou23: 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.

mananaysiempre: But legally distinct! I guess calling it Ｍ○ＰＳ was not enough for plausible deniability.

genxy: ISAs shouldn't be patentable in the first place.

cogman10: > AND the software with no architecture-specific optimisationsThe 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 determining where SIMD instructions could be placed).Unless these chips have very very weird performance characteristics (like the weirdness around x86's lea instruction being used for arithmetic) there's just not going to be a lot of missed heuristics.

unethical_ban: One could say "Optimize for efficiency first, then performance".

Aurornis: > A Banana Pi is not the fastest developer platform.What is the current fastest platform that isn’t exorbitantly expensive? Not upcoming releases, but something I can actually buy.I check in every 3-6 months but the situation hasn’t changed significantly yet.

NooneAtAll3: DC-ROMA 2 is on the Rasperry 4 level of performance last I heard

rwmj: 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.

fidotron: > 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?

STKFLT: I'd guess that the issue is running the `%install` and `%check` stages of the .spec file. The Python library rpy (to pull a random example from Marcin's PRs) runs rpy's pytest test suite and had to be modified to avoid running vector tests on RISC-V.Obviously a solvable problem to split build and test but perhaps the time savings aren't worth the complexity.https://src.fedoraproject.org/rpms/rpy/pull-request/4#reques...

hrmtst93837: One thing compilers still struggle with is exploiting weird microarchitectural quirks or timing behaviors that aren't obvious from the ISA spec, especially with memory, cache and pipeline tuning. If a new RISC-V core doesn't expose the same prefetching tricks or has odd branch prediction you won't get parity just by porting the same backend. If you want peak numbers sometimes you do still need to tune libraries or even sprinkle in a bit of inline asm despite all the "let the compiler handle it" dogma.

cptskippy: Core evolved from the Banis (Centrino) CPU core which was based on P3, not P4. Banias used the front-side bus from P4 but not the cores.Banias was hyper optimized for power, the mantra was to get done quickly and go to sleep to save power. Somewhere along the line someone said "hey what happens if we don't go to sleep?" and Core was born.

gt0: I don't think anybody suggests Oracle couldn't make faster SPARC processors, it's just that development of SPARC ended almost 10 years ago. At the time SPARC was abandoned, it was very competitive.

rwmj: 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 forNo one who is an expert in the field, and we (at Red Hat) talk to them routinely.

newpavlov: In some cases RISC-V ISA spec is definitely the one to blame:1) https://github.com/llvm/llvm-project/issues/1502632) https://github.com/llvm/llvm-project/issues/141488Another example is hard-coded 4 KiB page size which effectively kneecaps ISA when compared against ARM.

adastra22: 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.

fidotron: 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.

rllj: Which extension is that?

cogman10: 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.

pantalaimon: i686 builds even faster

pantalaimon: T2 manages to do ithttps://t2linux.com/