Is that versioning site supposed to be some kind of joke? I can't really figure out if they are joking or serious - the tone comes off as joking, but it could be read as serious too.
Given it's such a hot part of their code, I'm genuinely surprised they didn't go down the state machine route for as optimal a solution, or even further and made use of vector instructions. Maybe Rust can autovectorise the code though.
I think Highway is a critical component for libjxl and has to be counted towards the line count. (CMS can be ignored here, and any Rust implementation should ideally use qcms [1] which is already in use in Firefox anyway.)
Personally, I'm on the edge on this one. I think both viewpoints are valid.
One way to think of Highway is that it is portable multi-platform SIMD intrinsics for C++. While we developed it originally as a part of JPEG XL, it has long ago graduated into a general-purpose library that has various uses, including the recent Gemma.cpp ML launch. Other modern highway uses include: Audio, Browsers, Computational biology, Computer graphics, Cryptography, Grok JPEG 2000, JPEGenc, Jpegli, OpenHTJ2K, Image processing, Image viewers, Information retrieval, Machine learning, Numpy, and Robotics... (copied from: https://github.com/google/highway)
I derived the name from the CityHash, FarmHash, and then HighwayHash series, and considered that Highway would link this library to its roots in the HighwayHash (of course much is also based on Jan's previous work with SIMD). Notably, I resisted using the -li naming here :-D
Indeed, though Highway is approaching a system library at this point. It is also a thin wrapper over the compiler's intrinsics headers: e.g. ~16KLOC for arm_neon.h, times the number of targets. That's a lot of code, but it is not comparable with actual codec logic lines.
