qoi VS Halide

Her request is politely-phrased and reasonable. I don't think there's a legal or ethical issue, but respecting the wishes of others when it costs nothing is just kindness.

However, the way that some have seized on it, and then interacted with others in their communities is ... neither polite nor reasonable.

e.g. https://github.com/phoboslab/qoi/issues/35

How do you know it's not a problem for the people who work with computer vision? Let's take this for example - sure, the request itself was presented very unprofessionally, but this is still an example of someone in a computer vision-adjacent field stating in no uncertain terms that they have a problem with the image.

Yes. Without a supporting statement, it's ad hominem. But I provided a supporting statement.

This is the issue I'm taking about: https://mobile.twitter.com/richgel999/status/146443578680850...

Which links to here: https://github.com/phoboslab/qoi/issues/35

Where everyone agrees, yes, the image should be removed. They didn't know about its history. Would he please stop being a gigantic asshole about it.

So if that's not blowing things out of proportion, I don't know what is.

I don't know about CUDA, however I've made an AVX2 based encoder a few months ago : https://github.com/phoboslab/qoi/pull/143

I intend to create an AVX2 based decoder but I had absolutely no time to work on side projects in the past three months.

You might also want to take a look at this streaming encoder if you want to encode large files with a tiny memory footprint : https://github.com/MKCG/php-qoi/blob/main/src/FFI/lib/qoi.c

Not only does compression improve this situation today, but using QOI means improvements may continue to come over time. QOI is a very new, open source image format, and that's already proving to be an advantage. By itself, QOI compression is pretty weak, but YoYoGames have forked it and worked in BZ2 compression to surpass the old PNG format. As QOI itself improves and as YoYoGames continues to work on it, it's almost guaranteed that we'll see the compression ratio in GameMaker get better over time.

If CPU/GPU execution speed is the goal while simultaneously code golfing the source size, https://halide-lang.org/ might have come in handy.

This is a task where Halide https://halide-lang.org/ could really shine! It disconnects logic from scheduling (unrolling, vectorizing, tiling, caching intermediates etc), so every step the author describes in the article is a tunable in halide. halide doesn't appear to have bindings for golang so calling C++ from go might be the only viable option.

Probably would have been much easier to do 15 times in https://halide-lang.org/

The idea behind Halide is that scheduling memory access patterns is critical to performance. But, access patterns being interwoven into arithmetic algorithms makes them difficult to modify separately.

So, in Halide you specify the arithmetic and the schedule separately so you can rapidly iterate on either.

It is not the sorting per-se which was improved here, but sorting (particularly short sequences) on modern CPUs with really the complexity being on the difficulty of predicting what will work quickly on these modern CPUs.

Doing an empirical algorithm search to find which algorithms fit well on modern CPUs/memory systems is pretty common, see e.g. FFTW, ATLAS, https://halide-lang.org/

Halide https://halide-lang.org/

It doesn’t apply in this case, but in general if you really want the best vectorization I would suggest using https://halide-lang.org instead of trying to coerce your compiler.

If we drop the "APL" requirement, wouldn't Halide fit your criteria for the third?