15 ms·
Don't blame the ISA - blame the silicon implementations AND the software with no architecture-specific optimisations. RISC-V will get there, eventually. I rem
by rbanffy 8mo ago
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 8mo agoIF you care to read the article, they indeed do not blame the architecture but the available silicon implementations.
- rbanffy 8mo agoI 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.
- menaerus 8mo agoWhich risc-v implementation is considered fast?
- patchnull 8mo ago[flagged]
- menaerus 8mo agoI 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).
- LeFantome 8mo agoSpacemiT K3 is about the same performance as a Rockchip RK3588. So, 4 years ago? Except the K3 kills it on AI (60 TOPS).
- NooneAtAll3 8mo agoDC-ROMA 2 is on the Rasperry 4 level of performance last I heard
- LeFantome 8mo ago> 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.
- menaerus 8mo agoM4 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.
- gt0 8mo agoI 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.
- rbanffy 8mo agoProbably because that's just the infrastructure they have.
- pantalaimon 8mo agoi686 builds even faster
- kpil 8mo agoWhat'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.
- burntoutgray 8mo agoI thought I read somewhere that Z CPUs run at 5GHz ??
- Aurornis 8mo ago> 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.
- cestith 8mo agoWhat is the current fastest ppc64le implementation that isn’t exorbitantly expensive? How about the s390x?
- adgjlsfhk1 8mo agoA P550 based board is the best you can get for now (~2-3x faster than the Banana Pi). In 2-3 months there should be a number of SpaceMIT k3 chips that are ~4-6x faster than the banana pi and somewhat reasonably priced (~200-300). By the end of the year, however, you should be able to get an ascalon chip which should be way way faster than that (roughly apple m1/zen3 speed)
- snvzz 8mo ago>I did read it. A Banana Pi is not the fastest developer platform. The title is misleading. Ironically, its SoC (spacemiT K1) is slower than the JH7110 used in the first mass-produced RISC-V SBC, VisionFive 2. But unlike JH7110, it has vector 1.0, making it a very popular target. Of course, none of these pre-RVA23 boards will be relevant anymore, once the first development boards with RVA23-compatible K3 ship next month. These are also much faster than anything RISC-V currently purchasable. Developers have been playing with them for months through ssh access.
- tromp 8mo agoBut they didn't reflect that in a title like "current RISC-V silicon Is Sloooow" ...
- topspin 8mo agoI 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 8mo ago> At this point the most likely place for fast RISC-V to appear is China. Or we just adopt Loongson.
- balou23 8mo agoTBH 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 8mo agoBut legally distinct! I guess calling it Ｍ○ＰＳ was not enough for plausible deniability.
- genxy 8mo agoISAs shouldn't be patentable in the first place.
- pantalaimon 8mo agoThey did get rid of the delay slots and some other MIPS oddities
- bonzini 8mo agoLoongArch is, on a first approximation, an almost RISC-V user space instruction set together with MIPS-like privileged instructions and registers.
- mananaysiempre 8mo ago
- spiderice 8mo agoThen how do you justify the title?
- api 8mo agoA 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.
- jnovek 8mo agoI don’t have a micro architecture background so I apologize if this is obvious — What do power and speed mean in this context?
- McP 8mo agoPower - how many Watts does it need? Speed - how quickly can it perform operations?
- wmf 8mo agoYou can get low power with a simple design at a low clock. This definitely will not help achieve high performance later.
- weebull 8mo agoClock rate isn't the only factor. A design can be power hungry at a low clock rate if designed badly, and if it it is... you're never getting that think running fast.
- unethical_ban 8mo agoOne could say "Optimize for efficiency first, then performance".
- jauntywundrkind 8mo ago
- rwmj 8mo agoMarcin is working with us on RISC-V enablement for Fedora and RHEL, he's well aware of the problem with current implementations. We're hopeful that this'll be pretty much resolved by the end of the year.
- cogman10 8mo ago> 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 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.
- hrmtst93837 8mo ago[flagged]
- cogman10 8mo agoWhile 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.
- spockz 8mo agoNot all. CachyOS has specific builds for v3, v4, and AMD Zen4/5: https://wiki.cachyos.org/features/optimized_repos/ https://wiki.cachyos.org/features/optimized_repos/
- adrian_b 8mo agoSome applications may target a generic x86 architecture without any impact on performance. However, other applications which must do cryptographic operations, audio/video processing, scientific/technical/engineering computing, etc. may have wildly different performances when compiled for different x86-64 ISA versions, for which dedicated assembly-language functions exist.
- cogman10 8mo ago
- fidotron 8mo ago> 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.
- gt0 8mo agoI 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.
- twoodfin 8mo agoIn single-threaded performance? That’s not how I remember it: Sun was pushing parallel throughput over everything else, with designs like the T-Series & Rock.
- gt0 8mo agoPerhaps not single thread, but Rock was a dead end a while before Oracle pulled the plug, and Sun/Oracle's core market of course was always servers not workstations. We used Niagara machines at my work around the T2 era, a long time ago, but they were very competitive if you could saturate the cores and had the RAM to back it up.
- twoodfin 8mo agoSure, my work got a few of the Niagaras too and they were tremendous build machines for Solaris software. But if you’re judging an ISA by performance scalability, you generally want to look at single-threaded performance.
- icedchai 8mo ago
- newpavlov 8mo agoIn some cases RISC-V ISA spec is definitely the one to blame: 1) https://github.com/llvm/llvm-project/issues/150263 https://github.com/llvm/llvm-project/issues/150263 2) https://github.com/llvm/llvm-project/issues/141488 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.
- adastra22 8mo agoAlso 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 8mo agoThe 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 8mo agoWhich extension is that?
- mjmas 8mo agoAn extension he calls Xh3bextm. For extracting multiple bits from bitfields. https://wren.wtf/hazard3/doc/#extension-xh3bextm-section https://wren.wtf/hazard3/doc/#extension-xh3bextm-section There are also four other custom extensions implemented.
- wren6991 8mo agoThis extension wasn't strictly necessary but it makes decode of Arm instructions faster in the bootrom's Arm emulator.
- 8mo ago
- Dwedit 8mo agoThere's the ARM video from LowSpecGamer, where they talk about how they forgot to connect power to the chip, and it was still executing code anyway. According to Steve Furber, the chip was accidentally being powered from the protection diodes alone. So ARM was incredibly power efficient from the very beginning.
- bsder 8mo ago> Don't blame the ISA - blame the silicon implementations That's true, but tautological. The issue is that the RISC-V core is the easy part of the problem, and nobody seems to even be able to generate a chip that gets that right without weirdness and quirks. The more fundamental technical problem is that things like the cache organization and DDR interface and PCI interface and ... cannot just be synthesized. They require analog/RF VLSI designers doing things like clock forwarding and signal integrity analysis. If you get them wrong, your performance tanks, and, so far, everybody has gotten them wrong in various ways. The business problem is the fact that everybody wants to be the "performance" RISC-V vendor, but nobody wants to be the "embedded" RISC-V vendor. This is a problem because practically anybody who is willing to cough up for a "performance" processor is almost completely insensitive to any cost premium that ARM demands. The embedded space is hugely sensitive to cost, but nobody is willing to step into it because that requires that you do icky ecosystem things like marketing, software, debugging tools, inventory distribution, etc. This leads to the US business problem which is the fact that everybody wants to be an IP vendor and nobody wants to ship a damn chip. Consequently, if I want actual RISC-V hardware, I'm stuck dealing with Chinese vendors of various levels of dodginess.
- crest 8mo agoRISC-V lacks a bunch of really useful relatively easy to implement instructions and most extensions are truly optional so you can't rely on them. That's the problem if you let a bunch of academics turn your ISA into a paper mill. In theory you can spend a lot of effort to make a flawed ISA perform, but it will be neither easy nor pretty e.g. real world Linux distros can't distribute optimised packages for every uarch from dual-issue in-order RV64GC to 8-wide OoO RV64 with all the bells and whistles. Only in (deeply) embedded systems can you retarget the toolchain and optimise for each damn architecture subset you encounter.
- userbinator 8mo agoARM was never a "speed demon"; it started out as a low power small-area core and clearly had more complexity and thought put into it than MIPS or RISC-V. Over a decade ago: https://news.ycombinator.com/item?id=8235120 https://news.ycombinator.com/item?id=8235120 RISC-V will get there, eventually. Strong doubt. Those of us who were around in the 90s might remember how much hype there was with MIPS.
- rbanffy 8mo agoI don’t think you remember, But the first Archimedes smoked the just-launched Compaq 386s with a dedicated 387 coprocessor. It was not designed to be one, but it ended up being surprisingly fast.
- izacus 8mo agoIf you make a spec that the wider industry cannot effectively implement into quality products, it's the spec that's wrong. And that's true for anything - whether it's RISC-V, ipv6, Matter, USB-C and so on. That's what makes writing specs hard - you need people who understand implementation challenges at the table, not dreaming architects and academics.