JuliaLang
Allow taking Matrix slices without an extra allocation
Since changing Array to use Memory as the backing, we had the option of making non-Vector arrays more flexible, but had instead preserved the restriction that they must be zero offset and equal in length to the Memory. This results in extra complexity, restrictions, and allocations however, but doesn't gain any known benefits. Indeed, it makes it harder to allow resizing or reshaping Matrices completely flexibly. This PR aims to test if nanosoldier detects any benefit, or whether this restriction has outlived its usefulness.
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.
Looks like it gave LLVM a little bit of trouble on a few benchmarks, but overall seemed potentially worth doing this for the simplification of everything. I am not sure that overall it matters that much if LLVM removes boundschecking of a Matrix when indexing with eachindex? It is too bad though that IRCE might not know of this pattern already.
| ID | time ratio | memory ratio |
|---|---|---|
| ["array", "index", ("sumelt_boundscheck", "Matrix{Int32}")] | 4.00 (50%) ❌ | 1.00 (1%) |
| ["array", "index", ("sumelt_boundscheck", "Matrix{Int64}")] | 2.12 (50%) ❌ | 1.00 (1%) |
function perf_sumelt_boundscheck(A)
s = zero(eltype(A))
for i = 1:length(A)
s += A[i]
end
return s
end
looks like more negative than positive, but lots of the negative is ~5%
Probably mostly noise though, since it is worth noting this only affects code which uses Matrix (or rather, Array !<: Vector)
It's a bit scary that such a common for loop pattern gets a regression IMO
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.
Seems like vector of bignums are 10% faster, as expected now, but let's check
@nanosoldier runbenchmarks(!"scalar", vs=":master")
Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.