Add fast path in generic matmul

[jakobnissen]

This manually adds the critical optimisation investigated in JuliaLang/julia#56954. While we could rely on LLVM to continue doing this optimisation, it's more robust to add it manually.

[jishnub]

The performance regression doesn't seem to exist on the Julia master branch, which is what this repo is in sync with. This is probably because of various other refactorings. The issue is seen on v1.11.

We may still add this here though if this seems like a good idea. We'll just have to remember to make a separate PR to v1.11.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.88%. Comparing base (2a1696a) to head (cbe2f39).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1202      +/-   ##
==========================================
+ Coverage   91.86%   91.88%   +0.02%     
==========================================
  Files          34       34              
  Lines       15365    15366       +1     
==========================================
+ Hits        14115    14119       +4     
+ Misses       1250     1247       -3     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[jishnub]

Also, would you mind elaborating on what the specific optimization is in this case, and how you tracked it down?

[jakobnissen]

Yes - the optimisation is that, whenever Balpha == 0, then the entire loop:

@simd for m in axes(A, 1)
    C[m,n] = muladd(A[m,k], Balpha, C[m,n])
end

has no effect and can be skipped. You can verify by yourself on Julia 1.11.1 that a large bitmatrix with all zeros is much faster to multiply than one with ones.
I still don't know why this optimisation is only done sometimes.

I tracked it down by noticing that

• The difference in speed is 1000x for 3000x3000 matrices, which is too much to be explained by low-level details like whether it vectorizes or not, but points to an algorithmic difference
• Unix LinuxPerf (on suggestion from Gabriel Baraldi) showed the fast version executed several hundred times fewer instructions, and cache access, also pointing to actual less work being done, as opposed to doing the work more efficient
• Then, I carefully studied the generated native code until I found a jump instruction in the fast one that wasn't present in the slow one.

[jishnub]

Thanks a lot! I think this is good to merge.