As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation.
It’s very rare that the actual performance benefits of rust implementations come from rust itself (though it does often push you to slightly better patterns). They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.
The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++, as long as someone cares enough to do so.
> As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation.
I don't think anyone is claiming that. I took the GP's point as what was desired was a "safe, performant, compact, and compatible JPEG XL decoder in Rust" and "performant" (as defined as the speed of the c++ version) was passed two months ago.
> They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.
Sure, and looking at the recent commit histories, the team is focusing on getting the rust version ready for this milestone for obvious reasons, and is less concerned about immediate parity in the c++ codebase.
Usually what happens is you make the choice to do a Rust port or rewrite, you maintain the C++ for a while and then eventually the Rust port matches it on perf the the will to maintain the C++ version falls off a cliff.
Seeing this at $DAY_JOB already. I suspect soon at $DAY_JOB the only 2 low level languages approved for greenfield will be Rust and Ada/SPARK.
>As much as I enjoy rust, there is no reason why a c++ library can’t be optimised to match the rust implementation
but why would you bother? The rust library is the one that is being chosen to use. There is no point optimizing a library which is not going to be used.
> The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++
The obvious reason not to do this is that you lose the safety properties of it being written in Rust. What assurance do you have that there's not a memory error in the C++ version? It's similar but not purely a mechanical translation. Yes, you can port it back to C++, you can also port it to C or assembly or anything else you want. But why would you, especially for something like a codec?
No one was saying this was some indictment of c++. I agree with you that with any of these low-level, manual memory, compiled languages (c, c++, rust, zig, etc) the achievable performance is basically identical. But it's relevant to note that one implementation has surpassed another.
I suspect the real reason is safety. Rust isn't bulletproof but it's certainly much better than C++ when it comes to defending against memory corruption related attacks. And when you are building a decoder for untrusted data sent over the internet, this kind of thing matters a lot more.
I switched to an iPhone last year, mostly because I was getting sick of Samsung’s shit, and google doesn’t sell their pixel phones locally (and I don’t like Oppo).
But the other reason is that most of Android’s openness is quickly disappearing, so my main argument against iPhone is gone. And on the topic of privacy, I actually trust Apple way more than I trust the company that makes most of their revenue via advertising.
Exactly this. Once the writing was on the wall that deGoogled / FOSS Android was on borrowed time (at best), a ton of the argument against iOS dissolved overnight. We can argue that Apple's anti-repair policies and anti-user-customization policies are their own evils, sure, but at least my phone works for its core tasks, and works phenomenally well at that. My deGoogled Android phones were mostly hobbled together piles of "it sometimes works, as long as I don't look at it too funny". This tradeoff was fine for fully owning my data and being able to install absolutely anything I wanted on my phone. With arbitrary APK installation disappearing, and unlocked bootloaders to install a less hostile fork of Android becoming such a rarity these days, I may as well at least not fear looking at my phone the wrong way when the moon is in alignment with the wrong star.
Source: about 12 years of Android usage (11 of those on unlocked bootloaders and custom ROMs, ~6? of those deGoogled) -> iPhone 16e.
For the first half, custom ROMs were a massive boost to the experience, but I never really bothered after 2018; You had to install so much of google's stuff to get anywhere near proper experience that it just wasn't worth it, and even then many apps were starting to throw a fit when they detected a rooted device.
And at the same time, the stock android experience from most vendors was now good enough. I didn't even check custom ROM compatibly for my last Android two purchases (both Samsung). But it was nice to have the option of rooting and maybe finding/making a custom ROM Samsung removed that in their last update to One UI :(
For me it's the data-hoovering. I don't want Samsung (or Google, or Xiaomi, or whoever) background services phoning home my location every few seconds, or being able to uniquely track my device across apps, etc.
Once my ability to run a "background spyware-less" Android device went away, so did my willingness to put up with the negative sides of the usability tradeoff.
Apple probably sends some telemetry home, but at least their business model doesn't depend on knowing the exact Pantone color of the food I ate for dinner to market a matching wall paint to me.
Edit to add: oh, yeah, you mentioning 3P apps complaining if they detected root or MicroG reminds me of many a horrible night of debugging. Ugh. What a mess.
> You had to install so much of google's stuff to get anywhere near proper experience that it just wasn't worth it
What was it? Personally, the only thing I miss from stock Android is the Google Wallet/Pay/Wallet. (I do use microG to get push notifications and embedded maps working.)
Apple already have a huge chunk of the ad pie and are growing all the time. Dont think Apple are keeping you safe from ads and all the profiling of your behaviour that involves.
Apple are still far less reliant on advertising than google; They take far stricter stances against apps tracking users than google; And they actually let me an Adblock extension (or any other extension) in Safari.
Apple is not some magic solution to the question of on-device privacy. But compared to Android, the improvement is night and day.
Google are absolutely within the letter of the GPL, pedantically so. But maybe not the sprit.
We didn't have git tags when GPL was written in 1989, and while we did have sccs and rcs, (and early versions of cvs) they just weren't that widely used, and generally not used for distribution.
Even when GPL 3.0 was written in 2005-2007, source tarballs were still the primary form of distribution, even though it was starting to become standard to additionally provide anonymous cvs, svn, or one of the brand new distributed systems like git.
But these days git is the primary form of distribution, and source tarballs are noting more an afterthought. Hell, even tags are a bit of an afterthought on many projects. It's basically become the norm to expect an healthy revision history for any open source code.
Based on it's stated goals of "freedom to modify the software you use", IMO if the GPL was written (or updated) today, it would most likely require the distribution of revision history and restrict how much that history can be squashed/rewritten.
> We didn't have git tags when GPL was written in 1989
The GPLv2 requires "a medium customarily used for software interchange", not "a medium customarily used in 1989 for software interchange". Customs are the customs of the time someone is releasing the work.
“a medium customarily used for software interchange“
Interesting choice of cropping for that quote.
If you had included the previous word, it would be blindly obvious that “on a medium“ is only talking about the transport layer, not the format of the data. So it would exclude distributing source code on tape, or even optical discs, as nobody uses those anymore. About the only medium used for source code distribution these days is “the internet”
You could potentially stretch this to excluding google drive, though google will argue that the medium is http, not google drive; But you can’t stretch this to requiring it be formatted as git.
And even if you did manage to successfully argue that, google would just ship it as one (tagged) commit per release. The history would still be missing.
> If you had included the previous word, it would be blindly obvious that “on a medium“ is only talking about the transport layer, not the format of the data.
I can see your point. But OTOH if providing the "preferred form of the work for making modifications" requires not squashing commits into a big mess to frustrate someone trying to make sense of the code (I'm sure the Google engineers making modifications prefer to look at individual commits!), and Google is using Git anyway to create those commits, then it seems to me like there's an argument to be made that the customary medium used to interchange a range of Git commits is Git.
Yeah, that argument is much better; Maybe google are violating the GPL.
What that part of the GPL does absolutely forbid is stripping out the comments from the source code, or only shipping generated source files (but not the code which generated it). And arguably, git history is much of the same thing as comments. Especially when we have IDEs that can be configured to give us easy access to blame to help us understand the code.
The fact that commit history is not inline with the source code (or even stored as human readable files) makes it a little harder to see/argue that git history could be considered to be part of the source code, and I do wonder where this argument stops? Should the contents of bug trackers and PRs be considered to be part of the source code? What about design documents?
GPL says we need to be provided with the preferred form for modification. Those are the Git repositories for Android source code.
For Pixel kernel drivers, Google is converting the source code from the preferred form of dozens of Git repositories to a massive monolithic tarball. The build system used for this code expects it to be a bunch of Git repositories and spews out errors without it. It does build the code but it isn't the build process they used to do it themselves which is non-compliance. We need to be provided with what is needed to build it in the same way they built it.
Technically it could be expanded all the way to 640KB
But only the first 256 KB was on the motherboard, you needed a memory expansion card for the extra 384 KB, and I don't think they really existed in 1982.
Actually, you could somewhat break the 640KB limit in the early days (not that most people could afford that much RAM) days. Until EGA came along in 1984, there was free address space upto 704KB that you could use as conventional memory without much issue (or 736KB if you limited yourself to CGA).
And later we had the mess of EMS, which would work on the original 5150 with the right expansion card (and the right software to take advantage of it, like Lotus 123)
And on the RP2354 you can swap one or both ARM cores for RISC-V cores at boot.
I think the CH32v303's single V4F core might be slightly more capable than the Hazard 3 cores RISC-V cores (as it has a hardware FPU), but for everything else the RP2354 is probably better (and the ARM cores do have hardware FPUs)
Intel and AMD have proven that if you throw enough money at the problem, you can make fast microarchitectures despite a flawed ISA, and in many ways RISC-V is less flawed than x86. The things we are debating here are more along the lines of minor nitpicks.
The main roadblock to the existence of fast RISC-V cores is the entrenchment of large x86 and arm ecosystems.
> The main roadblock to the existence of fast RISC-V cores is the entrenchment of large x86 and arm ecosystems.
I'd disagree with that, their existence and decades of a head start mean they've been much more well invested but that's one of the things we're starting to see change, even if it's because of what would appear to be political motivations. We're starting to see a lot of investment into it in China because it looks like it's a reasonable way for tech sovereignty against the x86 monopoly. They've got licenses to some older (not sure about newer) AMD processor designs, I think around Zen2 architecture, for one of their major manufacturing firms but that won't easily let them move forward since they've got to do a lot of work to keep it up with compatibility and performance for newer ISA additions and such. That's one of the reasons they've been subsiding development of LoongSong64 and RISC-V to the point where for a while the larger LoongSong64 cores were illegal to export to some countries[0].
And then you've got a lot of other companies building faster RISC-V cores, for yes more embedded style designs but not the usual traditional embedded designs either. You've got TensTorrent working on AI work loads with real hardware out there that at least for ML stuff can compete on inference if you can get your software to run on it, and then you've got Bolt doing similar for GPU workloads[1]. While both of those are closer to embedded since you're not going to use them as a desktop, they're still making really fast RISC-V cores that could be theoretically turned into a standard RVA23 core by adding the missing extensions to make it work. That's of course not trivial but the entrenchment of x86 and arm aren't quite as daunting as they might have originally seemed.
It's still not as fast as I'd like, simply because I want to start seeing some RISC-V mini pcs get made that are fine for a daily driver office pc to happen.
You aren't disagreeing with the existence of the roadblock, just how hard it is to overcome.
And yes, there is a bunch of funding being pumped into it. I do have hope that some kind of RISC-V linux workstation will be viable in the next 5 years, without sacrificing too much performance or my wallet. I just wouldn't expect that to translate into making inroads into existing markets where x86 and arm have moats, like android/apple smartphones and more typical desktop/laptop workloads (even on linux).
I wouldn't count the AI/GPU stuff, those are generally pretty simple RISC pipelines with large vector units. Though TensTorrent do actually have a high-performance out-of-order rva23 core [1] that would be able to compete in this space. They are currently selling it as a "core for agentic workloads"
The XuanTie C950 looks pretty beefy for a RISC-V chip with integrated TPE. But it isn’t available commercially.
They are moving fast in China, wouldn’t be surprised if they offer a breaking integrated solution in the near future.
There aren’t any benchmarks available for the C950 but the comparisons go towards early Apple M-Series performance.
Before this, the author has never recommended others stay away from RISC-V, just stated their own distaste for it and a personal preference to use any other ISA if given a choice.
The two authors also have a very different definition of what "high-end" means.
Dmitry is talking about high-end application processors that you might find in a mid-range or better laptop, smartphone or server. Armstrong Subero seems to think that anything larger than a "dirt cheap microcontroller" is high-end.
People shouldn't take this the wrong way, but the VexRISC-V cores in Baochip are not "high-end". They are basically as low-end as you can get while still meeting the modern definition of "application core". And that doesn't matter, because being high-end application SoC is not Baochip's design criteria. These cores are actually pretty decent for Baochip's criteria.
The VexRISC-V are implementing the exact style of "classic-RISC" microarchitecture that RISC-V is optimised for. It's basically the optimal niche for RISC-V, before any of the problems start showing up.
I don't think I've ever seen anyone express the opinion that RISC-V can't easily cover the "dirt cheap microcontroller" to "low-end application processor" range, even stretching up into "mid-range application processor". Just that it's really fighting an uphill battle if it ever wants to compete with high-end application processors (and that it's going to struggle in the low-range/mid-range application market because of that).
To add to what you said, I don't see any big issues with high-end prosessors and licenses.
Anyone who spends $200 million to develop a completely new high-end processor microarchitecture every 3 to 5 years is not going to complain about an ARM license too much. You get freedom with $$.
Softbank and ARM managed to burn a lot of good-will with that bullshit (it is a bad sign when I'm siding with Qualcomm), and all for nothing as they lost that lawsuit. But is generally true that the $$ buys architecture licensees quite a bit of freedom.
Not as much freedom as they would get with something open like RISC-V, as ARM have strict rules around private ISA extensions (like how Apple doesn't publicly document AMX). But that extra control is generally a good thing for the health of the wider ARM ecosystem.
The really big problem is that $$ don't buy freedom, they buy freedom for your lawyers to talk with ARM's lawyers about what features you are allowed to build.
> That's why it's so bizarre that the RISC-V design is so awful.
Not bizarre.
The design is a direct result of the biases of its initial designers, and its original intended use-case. And TBH, if you assess it by its original design criteria, it's actually pretty good.
It's just by the time RISC-V had escaped containment and was starting to become a general purpose open ISA, it was a little too late to start from the beginning and consider what the correct design criteria should even be.
Very true... but I can't help but note that basically every person I've ever met with significant experience with multiple architectures at this level, and not connected in some way to RISC-V, utterly hates the thing.
It’s very rare that the actual performance benefits of rust implementations come from rust itself (though it does often push you to slightly better patterns). They usually come from the fact that rust implementations are usually a second (or 3rd, or 4th) iteration of the design, and the lessons learned help performance.
The other benefit of rust is that the stronger type system makes it easier to iterate and optimise without bugs creeping in. But once optimisations are implemented in rust, there isn’t that much pain to porting them back to c++, as long as someone cares enough to do so.
reply