Improve type-stability in _vcor

[jishnub]

Fix #30
The main change in this PR is to replace Tuples by Vectors, as the size of an array will not be type-inferred in general. Also replace 1:m by the corresponding array axis, which may help preserve static array sizes (aside from being safer when indexing into an array).

After this,

julia> using Statistics, VectorizedStatistics, BenchmarkTools

julia> a = rand(50, 50);

julia> @btime cor($a, dims=1);
  16.986 μs (12 allocations: 40.72 KiB)

julia> @btime vcor($a, dims=1);
  27.638 μs (4 allocations: 20.58 KiB)

Ideally, this should be even faster, but at least it's in the same ballpark now.

A further improvement may be to use aggressive constant propagation, which may help improve type-inference for static arrays, where each axis may have a different size. This isn't included in this PR.

[brenhinkeller]

Thanks for the PR! Looks like the @constprop isn't available in 1.6 but I'm fine with dropping support for 1.6..
Any thoughts on this @chriselrod?

[chriselrod]

I'm fine with dropping 1.6 / have little personal interest in supporting LTS versions. Julia is far more stable than the package ecosystem, so the position of wanting to be on a Julia LTS but upgrading to the latest versions of packages doesn't make sense to me.

What is an example of the inference failure? Statically sized arrays, so individual axes have different types?

Do we want to union split over the possibilities?

[brenhinkeller]

Since IIRC this method is only for AbstractMatrix, maybe it's just worth just branching on dims...

I'm not sure I've fully understood why the original method was so slow yet, but could reproduce

[jishnub]

Perhaps we can look at static arrays later, since more work needs to be done to get them to play nicely with LoopVectorization.

One further improvement that I can think of is to fill in only the lower triangular part of the output matrix, and wrap a Symmetric around it. This should reduce cache-misses significantly, and may also improve downstream performance. This may be mildly breaking, though, and would mean taking on LinearAlgebra as a dependency.

Edit: I tried the Symmetric approach and this doesn't seem to improve things by a lot, since vcov is the most expensive step by far. Still something to consider, perhaps.

[brenhinkeller]

Ok, I'll go ahead and merge since it was probably a mistake of me to use tuples there originally, can see if there's a way to avoid the extra allocation in the future