Reduce number of test combinations in test/triangular.jl

[andreasnoack]

Currently, we are most likely testing more cases of mixed element types than needed. See #1117. This PR reduces the mixed cases to (Int, Float32) and (Float32, Int) to get an idea how much of a difference it makes for the CI time.

[andreasnoack]

@KristofferC Btw. I wanted to run some timings locally on my mac but the system image build hadn't finished after two hours so I interrupted it. Any idea why it would take so long? I used current release of Julia and the latest version of PackageCompiler

[KristofferC]

Possibly related to JuliaLang/PackageCompiler.jl#990. So make sure that is not set.

[andreasnoack]

Thanks. Indeed that was the issue. Now I can build a new system image but I'm hitting

julia> S = SizedArrays.SizedArray{(3,3)}(reshape(1:9,3,3))
3×3 Main.SizedArrays.SizedArray{(3, 3), Int64, 2, Base.ReshapedArray{Int64, 2, UnitRange{Int64}, Tuple{}}} with indices SOneTo(3)×SOneTo(3):
 1  4  7
 2  5  8
 3  6  9

julia> convert(AbstractMatrix{Float64}, S)
ERROR: MethodError: no method matching similar(::Main.SizedArrays.SizedArray{…}, ::Type{…}, ::Tuple{…})
The function `similar` exists, but no method is defined for this combination of argument types.

Closest candidates are:
  similar(::Base.Broadcast.Broadcasted{Base.Broadcast.ArrayConflict}, ::Type{ElType}, ::Any) where ElType
   @ Base broadcast.jl:229
  similar(::Base.Broadcast.Broadcasted{Base.Broadcast.DefaultArrayStyle{N}}, ::Type{ElType}, ::Any) where {N, ElType}
   @ Base broadcast.jl:224
  similar(::AbstractArray, ::Type{T}, ::NTuple{N, Int64}) where {T, N}
   @ Base abstractarray.jl:833

when running with Julia 1.11. Is that known and the reason why you set up testing with 1.10 in this repo (was confused by this)?

Update: can see that this is not an issue on nightly.

[KristofferC]

This PR is against the one with O0. Is that intended?

[KristofferC]

I updated this to only have the eltype change so we can see the effect.

[andreasnoack]

I started with the run. It's here https://buildkite.com/julialang/linearalgebra-dot-jl/builds/45#01936fb4-b7f2-44f7-bc1e-dd6696b8fcce and then moved the target to see the combined effect which is https://buildkite.com/julialang/linearalgebra-dot-jl/builds/46#019371c1-e511-480a-b72c-150fee510177. It looks like the -O0 benefits almost all, if not all, the test groups so I think we should move forward with both of these changes.

[KristofferC]

So with only this change, it takes 24 minutes. The combined change seems to have taken 23 minutes, or?

[andreasnoack]

The actual tests are about five minutes faster. With just this PR, it is

Test Summary:  Pass  Broken   Total      Time
--
Overall      130954      63  131017  16m58.6s

and when adding the -O0 PR, it is

Test Summary:                        Pass  Fail  Broken   Total      Time
--
Overall                            135342     4      63  135409  11m39.0s

(not sure why the test total is different). I guess the total times don't show the same difference because of more compile time. Could that be because the system image is generated with a different optimization setting? It's not clear to me where the extra time is spent.

[andreasnoack]

Tried another run against #1118 to see if it was just a single slow run but the second run was pretty similar to the first. The actual tests run ~5 minutes faster but something else is taking some time so the total difference is only 1-2 minutes.

I've moved the target back to master and will rebase shortly. Then we can move forward with this one and consider #1118 separately.

[KristofferC]

Sounds good!