Luca Versari, one of the devs between both libraries, has a performance dashboard to compare performance between the two
https://jxl-rs-perf.lucaversari.it/
jxl-rs started to outperform the C++ library 2 months ago.
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 then 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?
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.
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.
If he is one of the devs between both libraries, why is there a performance gap? Why not port the optimizations from one lib to the other? You can even create a pinned agent workflow that automatically translates optimizations between repos. Fairly trivial to implement actually.
Just because you can theoretically write equivalent code in both languages doesn't mean two idiomatic implementations in each language will be 1:1 with each other. I haven't looked at the code in question, but some examples of common differences:
A C++ program might do template metaprogramming at compile time and the same thing at runtime in Rust, or vice versa. The C++ version might use virtual functions that rust wouldn't use. The Rust version might simply give more optimization information to the backend. The C++ version might use fairly awful parts of the stdlib like iostreams or shared_ptr that rust simply implements better. Etc.
Or maybe they're just focused on the rust implementation as they should be.
The rust borrow checker makes it difficult to implement tree like structures with pointers like you would in C or C++. Safe rust trees are (imo) best written using vecs.
Rust makes function arguments noalias.
Rust adds runtime array bound checks.
Rust and C++ do iteration quite differently. Rust encourages map/filter/reduce. I suspect this results in different assembly.
Doing a “unity build” in rust is really easy (codegen-units=1). In C++, you need to make heavy modifications to your build system and sometimes your source too.
But with some time you could probably port the optimisations across. If anyone has some spare tokens, Claude can be quite good at doing this sort of work. Show it both repositories and tell it to make the C++ code just as fast as rust.
Git-ish CLI is great. The GUI is more important though. Non-programmers don't want to dabble with CLI. One reason why Perforce is the defacto standard IMO. The GUI covers 99% of daily used operations and is easy to use.
People asking any AI chat interface for ideas for their honeymoon will trigger some kind of search.
SEO is still relevant and Google might still be able to sell top spots in their search so LLMs will pick it up.
exactly. Claude is in a niche. It's a high-value niche right now, but a niche nonetheless. Normies don't use claude much based on the numbers I saw. Search is still highly relevant and Google seems well positioned to capitalize on it.
Maybe that's what I don't get. Ferraris in my mind need to be great at two things:
Going 300kph around a racetrack and going 3kph in front of Harrods. If I want a comfy way to get my family around, I'd get a Mercedes.
jxl-rs started to outperform the C++ library 2 months ago.