@sahib can you address the linting and other CI issues here?

@sahib can you address the linting and other CI issues here?

I tried to fix the linting (I think you have to trigger the pipeline explicitly?).

Interestingly, those were not broken due to my changes, but the template was wrong. I still have (at least one) one failing test locally. I think this fails rightfully so, since strcvonv.ParseInt() will not parse stuff like Nan or +Inf. Should it be strconv.ParseFloat() or should this just not work for Ints?

@zeroshade: I've gone with the more likely option of fixing the test cases.

OT question: How hard would you think would it be to enable the asm optimizations also for arm(32)? I noticed they do help a lot on arm64 and would be great to have them there as well.

@sahib I haven't tested generating the asm for ARM32 and I don't have an ARM32 system that I could test it on if I were to generate it.

In the ideal scenario, it should be really easy to generate the assembly via adding the entries to the Makefiles, but I'm sure it won't be that simple.

@zeroshade I can give it a try once I get a chance. Maybe finally an excuse to learn Go Assembler for me...
From my understanding it should be mostly compatible and it's easy to test with a raspberry pi (+32bit OS).

I guess this PR can be merged?

@zeroshade More a minor thing I also noticed and might be worth sharing:

Most of the asm functions are selected over function variables during runtime (i.e. during init() different implementation are set based on cpu functions). Overall a nice approach, but it comes with a small performance penalty, as this prohibits inlining (and maybe some more things?).

Considering this mini benchmark:

func BenchmarkTestGreaterThanBitmap(b *testing.B) {
	const N = 10
	levels := make([]int16, N)
	for idx := range levels {
		levels[idx] = int16(idx)
	}

	b.Run("func", func(b *testing.B) {
		for b.Loop() {
			GreaterThanBitmap(levels, int16(N/2))
		}
	})

	b.Run("no-func-go", func(b *testing.B) {
		for b.Loop() {
			greaterThanBitmapGo(levels, int16(N/2))
		}
	})
}

# noasm to make sure that we do not compare against arch specific function
$ go test -tags noasm -bench=. -run=xxx
BenchmarkTestGreaterThanBitmap/func-16         	165481227	        7.289 ns/op
BenchmarkTestGreaterThanBitmap/no-func-go-16   	243919600	        4.611 ns/op

That difference of course is negligible if the function runtime increases. But overall it would be probably possible to squeeze out a few percent of benchmark speed when changing those function values to something along the lines:

func ExtractBits(...) {
    if cpu.X86.HasBMI2 {
        return extractBitsGo(...)
    }

    return extractBitsBMI()
}

I did push a dummy branch here: https://github.com/sahib/arrow-go/tree/bench/build-tag - seems like the whole platform selection gets less convoluted using this approach as well. All in all more minor stuff, but I wanted your opinion on this first.

Yup, I'll approve and merge this.

Most of the asm functions are selected over function variables during runtime (i.e. during init() different implementation are set based on cpu functions). Overall a nice approach, but it comes with a small performance penalty, as this prohibits inlining (and maybe some more things?).

If I remember correctly, the Go compiler isn't able to inline assembly functions like this in the first place so we wouldn't be able to inline anyways.

I did push a dummy branch here: https://github.com/sahib/arrow-go/tree/bench/build-tag - seems like the whole platform selection gets less convoluted using this approach as well. All in all more minor stuff, but I wanted your opinion on this first.

I like the idea, as long as the benchmarks in your branch support the idea and don't cause any performance regressions