LinearAlgebra: Do not specialize arguments in check_A_mul_B!_sizes

[jishnub]

Since this is a check that only depends on the sizes of the matrices, we do not need to specialize the method for the types of the matrix arguments. This would reduce TTFX if the method is called for three or more combinations of argument types (the break-even is at two, and this implementation is strictly worse if the method is only called once). However, the TTFX is hardly a factor if it is only called once.

On v"1.12.0-DEV.875"

julia> using LinearAlgebra

julia> n = 5; B = Bidiagonal(rand(n), rand(n-1), :U); D = Diagonal(rand(size(B,1))); C = similar(B, size(B));

julia> @time LinearAlgebra.check_A_mul_B!_sizes(C, B, D);
  0.010095 seconds (7.68 k allocations: 371.203 KiB, 99.76% compilation time)

julia> @time LinearAlgebra.check_A_mul_B!_sizes(C, D, B);
  0.008804 seconds (5.74 k allocations: 275.203 KiB, 99.79% compilation time)

julia> C = similar(B);

julia> @time LinearAlgebra.check_A_mul_B!_sizes(C, B, D);
  0.007851 seconds (5.83 k allocations: 279.781 KiB, 99.78% compilation time)

julia> @time LinearAlgebra.check_A_mul_B!_sizes(C, D, B);
  0.008116 seconds (5.84 k allocations: 280.031 KiB, 99.77% compilation time)

This PR

julia> @time LinearAlgebra.check_A_mul_B!_sizes(C, B, D);
  0.022551 seconds (11.69 k allocations: 550.625 KiB, 99.58% compilation time)

julia> @time LinearAlgebra.check_A_mul_B!_sizes(C, D, B);
  0.000014 seconds (3 allocations: 96 bytes)

julia> C = similar(B);

julia> @time LinearAlgebra.check_A_mul_B!_sizes(C, B, D);
  0.000013 seconds (3 allocations: 96 bytes)

julia> @time LinearAlgebra.check_A_mul_B!_sizes(C, D, B);
  0.000013 seconds (3 allocations: 96 bytes)

[mikmoore]

Since this is a check that only depends on the sizes of the matrices, we do not need to specialize the method for the types of the matrix arguments.

Disclosure: I've never fully understood the implications and impact of @nospecialize.

But surely the size function can be different among different types? Do I misunderstand? Or is the statement simply that this function is not worth specializing, since it's seldom a performance-sensitive part of a calculation?

[jishnub]

size for common AbstractMatrixes very frequently returns a Tuple{Int,Int}, although it may in principle return other element types such as BigInt, or other types such as infinities. Probably worth checking the impact in such cases.

[mikmoore]

Thanks. I think that it's not unreasonable to expect that most types (and especially most types being checked by this method) will return a Tuple{Int,Int} from size. I don't take issue with that.

I had incorrectly assumed a successful @nospecialize would result in dynamic dispatch into the proper size method. Reading the manual more closely, it appears that is the domain of Base.@nospecializeinfer. My bad, and thanks for the correction.

[dkarrasch]

Can't we simply switch to the call pattern A_mul_B!_sizes(size(C), size(A), size(B)) instead? This is an internal function, so I wouldn't expect anything to break.

[jishnub]

The test failure is unrelated, so should we go ahead with this?