avo VS Halide

I wonder whether avo could have been useful here?[1] I mention it because it came up the last time we were talking about AVX operations in go.[2]

1 = https://github.com/mmcloughlin/avo

2 = https://news.ycombinator.com/item?id=34465297

I thought the /r/golang comments on this post were pretty useful[1]. They also introduced me to avo[2], a tool for generating x86 assembly from go that I hadn't seen before. There are some examples listed on the avo github page for generating AVX512 instructions with avo.

1 = https://www.reddit.com/r/golang/comments/10hmh07/how_to_use_...

2 = https://github.com/mmcloughlin/avo

For writing AVX512 from scratch avo is a much better alternative.

Avo is a library that simplifies writing complex go assembly, I found it very useful to figure out how instructions map onto Go's asm syntax. But you could definitely do the translation directly, it's what c2goasm did (couldn't get it to work reliably unfortunately).

Curious if you're looking at using avo to write the assembly

You can use github.com/mmcloughlin/avo for generating the assembly use Go.

For normal and "better" mode I am using avo to generate different encoders for different input sizes, with and without Snappy compatibility. That currently outputs about 17k lines of assembly.

You could perhaps just have the Go compiler generate the assembler for your code:

go tool compile -S file.go > file_amd64.s

Then you could verify it doesn't change over time, and choose to begin maintaining by hand if it makes sense.

If you do want to go the route of rolling it yourself, I'd suggest looking into something like Avo: https://github.com/mmcloughlin/avo

If you have to go with Assembly, try Avo https://github.com/mmcloughlin/avo

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?