fpnge

In a similar vein: https://github.com/veluca93/fpnge https://x.com/LucaVersari3/status/1485971553892323333

https://github.com/veluca93/fpnge is a very fast png encoder. A bit lower compression ratio, but runs significantly faster than alternatives. Here is a presentation with benchmarks: https://www.lucaversari.it/FJXL_and_FPNGE.pdf

I didn't infer 15% from the way it was written there. But most platforms these days have some form of CRC32 "acceleration". Adler32 is easy to compute so I'm even less concerned there. I spent a bunch of time optimising the code in fpnge (https://github.com/veluca93/fpnge), which is often notably faster than fpng (https://github.com/nigeltao/qoir/blob/5671f584dcf84ddb71e28d...), yet checksum time is basically negligible. Having said that, the double-checksum aspect of PNG does feel unnecessary.

Ooh now that is very interesting. I would really love to see how this speeds up the run-time of fpng as a whole, if you have any numbers. It looks like fjxl [0] and fpnge [1] (which also uses AVX2) are at the Pareto front for lossless image compression right now [2], but if this speeds things significantly then it's possible there'll be a huge shakeup! [0] https://github.com/libjxl/libjxl/tree/main/experimental/fast... [1] https://github.com/veluca93/fpnge [2] https://twitter.com/richgel999/status/1485976101692358656

Nice! > For deferring the madd specifically, using two separate sum2 vectors and splitting the `mad` vector into two Actually, the idea was to accumulate into 16-bit sums, and only do madd to 32-bit every 4 loop cycles. I'm not sure splitting it up like that actually helps, since the latency can be easily hidden by an OoO processor, and could actually be detrimental adding more uOps. One thing to note is that you've got a dependent add chain on sum2_v, so using two independent sums instead of one could help. > Plus I am sure there are many other opportunities to optimize this I have not thought of :) Other implementations I've seen don't go any further, e.g. https://github.com/zlib-ng/zlib-ng/blob/develop/arch/x86/adl... https://github.com/veluca93/fpnge/blob/9a9fc023870bacd06674f... So perhaps as you allude to, it isn't really worth it.

I wonder how fpng[1] would compare- a lossless speed optimized png compressor. Oh! The author Rich screenshoted[2] a really nice deck[3] that also boasts fpnge[4] and fjxl[5], both of which are even faster, both use AVX2 (or neon for FJXL). Notably fjxl is in the reference libjxl tree. I'm not sure what if any constraints fast mode has, what it takes to use. The article uses cjxl, which does not run the fjxl fast mode, and further, fast mode was added after this article was written[6]. Other notes on jpeg-xl: it has progressive rendering. It has hdr! The deck on FJXL & FPNGE is epic. Thanks Quote Ok Image (QOI) format for setting the fire on this all!! [1] https://github.com/richgel999/fpng [2] https://twitter.com/richgel999/status/1485976101692358656 [3] https://www.lucaversari.it/FJXL_and_FPNGE.pdf [4] https://github.com/veluca93/fpnge

QOI is not on the pareto frontier for compression [1], it is however extremely simple and is a nice introduction to data compression for anyone wanting to learn about the field. [1] See: https://www.lucaversari.it/FJXL_and_FPNGE.pdf https://github.com/libjxl/libjxl/tree/main/experimental/fast... https://github.com/veluca93/fpnge