Earlier quoted context omitted.
P550 is, like, what, only a year old? I suppose there has been some laughing at it at least. Also Kendryte K230 / C908, but only on vector mem ops, which adds a whole another mess onto this. I'd hope all the massive OoO will have fast misaligned mem ops, anything else would immediately cause infinite pain for decades. But of course there'll be plenty of RVA23 hardware that's much smaller eventually too, once it becom…
> I do agree that it'd be reasonable to just assume fast misaligned ops, but for whatever reason gcc and clang just don't, and that's what we have for defaults. This very much has a "for now" on it. Once there is actually widespread hardware with the feature, I would be very surprised if the compilers don't update their heuristics (at least for RVA23 chips)
RISC-V Is Sloooow
361–370 of 397 posts
Re: RISC-V Is Sloooow
#362Re: RISC-V Is Sloooow
#363Earlier quoted context omitted.
So it's modular. This is normally considered a good thing. It means you don't have to pay for features you don't need. The ISA is open so there's no greedy corporation trying to upsell you. I mean there's an implementation and die area cost for each extension but it's not being set at an artificial level by a monopolist.
But that means a port of Linux can’t be to RISC-V, it has to be to a specific implementation of RISC-V, or if sufficient (which seems still debatable) to a specific common RISC-V profile.
In what way are RISC-V profiles debatable? Canonical is spearheading the RVA23-as-a-default movement and so far, it seems that there are no heavy objections towards that effort (beyond the usual "Canonical sucks" shtick that you see in every discussion involving Canonical)
Re: RISC-V Is Sloooow
#364Earlier quoted context omitted.
Then you stick to RVA23, which is comparable to ARMv9 and x86-64v4.
RVA23 is, finally, the belated admission that maybe we shouldn't have everything as optional extras. Hopefully it'll take off, I can't imagine what sort of a headache it is for maintainers of repos who have to track a dozen different variants of binaries depending on which flavour of RISC-V the apt-get is coming from.
As for general purpose processors, RISC-V has always had the idea of profiles (mandatory set of extensions). Just look at the G extension, which mandated floating point, multiply/division, atomics, ... things that you expect to see on user-facing general-purpose processors.
> the belated admission that maybe we shouldn't have everything as optional extras
That's why I disagree with the above claim.
(1) The optionality is a feature of RISC-V and it allows RISC-V to shine on different ecosystems. The desktop isn't everything.
(2) RISC-V has always addressed the fear of fragmentation on the desktop by using profiles.
Re: RISC-V Is Sloooow
#365That is the same as the time he quotes for the unidentified Aarch64 hardware.
Which makes this a pretty funny article.
I do not have a K3 to confrim. I am hoping to pick one up when it becomes more widely available next month.
Re: RISC-V Is Sloooow
#366Earlier quoted context omitted.
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.
> lots of commercial software is now compiled for newer x86 64 extensions. Almost all software I encountered - including Windows 10 and precompiled Debian 13 - needs only SSE4.2, essentially mid-2000s ISA. Intel produced until very recently (early 2020s) Celeron CPUs which did not even support AVX.
Re: RISC-V Is Sloooow
#367The reason that he does not tell us what hardware he is using is because none of these times are for a single system building binutils. I think he is using a mix of systems and then doing some kind of averaging to tell us what a individual system would look like.
For some kind of hardware, all the systems they have would be the fastest that architecture offers, like with i686 I expect. While others are going to be a mix of old and new, like x86-64.
For RISC-V, the latest gen hardware is about as fast as the numbers he quotes for Aarch64. To be clear, the fastest ARM is still faster than the fastest RISC-V. But the numbers he quotes make no sense for something like a SpacemiT K3.
But if you are using RISC-V systems from two years ago in your build cluster, they will as he says be "Sloooow". But that shows how fast RISC-V is improving. It makes no sense to publish this article now.
At least, he should reveal what hardware he is talking about. His chart makes no sense (for most of the platforms).
Re: RISC-V Is Sloooow
#368Earlier quoted context omitted.
>What kind or ancient arm hardware are they using here? I think that's the point being made here. ARM in the 2000s was not known to be fast, now it is. RISC-V being slow isn't an inherent characteristic of the ISA, it only tells you about the quality of its implementations. And said implementations will only improve if corporations are throwing capitals at it (see: Apple, Qualcomm, etc.)
I think standard Arm cores are already plenty fast, the issue is the SoC vendors are still using cortex-A57 from 2015 instead of the new designs.
Re: RISC-V Is Sloooow
#369A couple of corrections (the blog-post is by a colleague, but I'm not speaking for Marcin! :)) First, we do have a recent 'binutils' build[1] with test-suites in 67 minutes (it was on Milk-V "Megrez") in the Fedora RISC-V build system. This is a non-trivial improvement over the 143-minute build time reported in the blog. Second, the current fastest development machine is not Banana Pi BPI-F3. If we consider what is r…
> VisionFive 2 It's a good solid reliable board, but over three years old at this point (in a fast-moving industry) and the maximum 8 GB RAM is quite challenging for some builds. Binutils is fine, but on recent versions of gcc it wants to link four binaries at the same time, with each link using 4 GB RAM. I've found this fails on my 16 GB P550 Megrez with swap disabled, but works quickly and uses maybe 50 or 100 MB o…
I see, I don't have a Megrez at my desk, only in the build system. I only have P550 as my "workhorse".
PS: I made a typo above - the P550 I was referring to was the SiFive "HiFive Premier P550". But based on your HN profile text, you must've guessed it as much :)
Re: RISC-V Is Sloooow
#370Earlier quoted context omitted.
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
Why? They have yet to show anything to believe in except perhaps the embedded space.
You think the Alibaba C930 CPU is for embedded? 15 SPECint2006 / GHz
Or that the Tenstorrent Ascaclon will be? 18 SPECint2006 / GHz
Even the SpacemiT K3 has better AI performance than an Apple Silicon M4.
And RISC-V chips released this year are 2-4 times faster than last year. RISC-V is not the fastest ISA but it is improving the fastest.
With so many companies backing RISC-V, why would I bet against it?