highway VS jpeg-xl

The bf16 dot instruction replaces 6 instructions: https://github.com/google/highway/blob/master/hwy/ops/x86_12...

[0] for those interested in Highway.

It's also mentioned in [1], which starts off

> Today we're sharing open source code that can sort arrays of numbers about ten times as fast as the C++ std::sort, and outperforms state of the art architecture-specific algorithms, while being portable across all modern CPU architectures. Below we discuss how we achieved this.

[0] https://github.com/google/highway

[1] https://opensource.googleblog.com/2022/06/Vectorized%20and%2..., which has an associated paper at https://arxiv.org/pdf/2205.05982.pdf.

Thanks so much!

Everyone working on this self-selected into contributing, so I think of it less as my team than ... a team?

Specifically want to call out: Jan Wassenberg (author of https://github.com/google/highway) and I started gemma.cpp as a small project just a few months ago + Phil Culliton, Dan Zheng, and Paul Chang + of course the GDM Gemma team.

C++ users can enjoy Highway [1].

[1] https://github.com/google/highway/

At that point it is better to have some kind of DSL that should not be in the main language, because it would target a much lower level than a typical program. The best effort I've seen in this scene was Google's Highway [1] (not to be confused with HighwayHash) and I even once attempted to recreate it in Rust, but it is still distanced from my ideal.

[1] https://github.com/google/highway

Interesting, thanks for sharing :)

At the time we open-sourced Highway, the standardization process had already started and there were some discussions.

I'm curious why stdlib is the only path you see to default? Compare the activity level of https://github.com/VcDevel/std-simd vs https://github.com/google/highway. As to open-source usage, after years of std::experimental, I see <200 search hits [1], vs >400 for Highway [2], even after excluding several library users.

But that aside, I'm not convinced standardization is the best path for a SIMD library. We and external users extend Highway on a weekly basis as new use cases arise. What if we deferred those changes to 3-monthly meetings, or had to wait for one meeting per WD, CD, (FCD), DIS, (FDIS) stage before it's standardized? Standardization seems more useful for rarely-changing things.

1: https://sourcegraph.com/search?q=context:global+std::experim...

2: https://sourcegraph.com/search?q=context:global+HWY_NAMESPAC...

Thanks for the link. We were previously using GFNI for bit reversal and 8-bit shifts, and I just extended that to our 8-bit BroadcastSignBit (https://github.com/google/highway/pull/1784).

You could study Google's Highway library [1].

[1] https://github.com/google/highway

Runtime feature detection need not be rare nor hard, it's a few dozen lines of boilerplate. You can even write your code just once: see https://github.com/google/highway#examples.

I believe JXL's reference implementation isn't even to version 1 yet. 0.8.1 appears to be the latest. I could see them revisiting this once the reference implementation is considered complete.

I asked for this a while ago, not sure how things have progressed since then.

That license doesn't say anything about patents. This one does: https://gitlab.com/wg1/jpeg-xl/-/blob/main/PATENTS and only says that patents owned by Google are covered. So it may be that other companies patent the technology. The information in the repository is not enough to decide whether JPEG XL is safe to use.

The GIMP plugin is a great thing. But it still can't open/save images with special chars in their filenames. French, German and many other languages are affected. Could this be fixed soon? https://gitlab.com/wg1/jpeg-xl/-/issues/184

https://gitlab.com/wg1/jpeg-xl/-/blob/main/doc/developing_in_windows.md It's not as straight-forward to build as it is on Linux. I'm not sure if there are official binaries somewhere, sorry.

I'm guessing the reference implementation with complete git history is soon to follow? https://gitlab.com/wg1/jpeg-xl

The file format was 'frozen' last December: https://gitlab.com/wg1/jpeg-xl/-/tags/v0.2 Which is why FF can start implementing its usage.