6 ms·

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 b

by phire 22d 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.

magicalist 22d ago
> 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.
hn92726819 22d ago
I don't understand why anyone would continue working on the c++ project once the rust one started beating it in performance
- Snafuh 22d ago
  jxl-rs (rust) is just a decoder while libjxl (C++) can also encode. There is a rust encoder in active developing by someone outside the core JPEG XL devs.
- BoingBoomTschak 22d ago
  To catch conformance issues by comparing two implementations. Perhaps to support obscure platforms only available through gcc.
pibaker 22d ago
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.
- Lvl999Noob 22d ago
  For safety in decoding, isn't there WUFFS, also by Google, that's guaranteed safe and fast?
  - yboris 21d ago
    TIL: wuffs - Wrangling Untrusted File Formats Safely https://github.com/google/wuffs https://github.com/google/wuffs
bawolff 22d ago
>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.
bastawhiz 22d ago
> 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?
pkulak 22d ago
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.
jpgvm 22d ago
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.

by phire 22d ago

magicalist 22d ago

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

hn92726819 22d ago

I don't understand why anyone would continue working on the c++ project once the rust one started beating it in performance

Snafuh 22d ago
jxl-rs (rust) is just a decoder while libjxl (C++) can also encode. There is a rust encoder in active developing by someone outside the core JPEG XL devs.
BoingBoomTschak 22d ago
To catch conformance issues by comparing two implementations. Perhaps to support obscure platforms only available through gcc.

pibaker 22d ago

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.

Lvl999Noob 22d ago
For safety in decoding, isn't there WUFFS, also by Google, that's guaranteed safe and fast?
- yboris 21d ago
  TIL: wuffs - Wrangling Untrusted File Formats Safely https://github.com/google/wuffs https://github.com/google/wuffs

bawolff 22d ago

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

bastawhiz 22d ago

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

pkulak 22d ago

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.

jpgvm 22d ago

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.