Remove bugged and typically slower minimum/maximum method

[mbauman]

This method intends to be a SIMD-able optimization for reductions with min and max, but it fails to achieve those goals on nearly every architecture. For example, on my Mac M1 the generic implementation is more than 6x faster than this method:

julia> A = rand(Float64, 10000);

julia> @btime reduce(max, $A);
  4.673 μs (0 allocations: 0 bytes)

julia> @btime reduce((x,y)->max(x,y), $A);
  718.441 ns (0 allocations: 0 bytes)

I asked for some crowd-sourced multi-architecture benchmarks for the above test case on Slack, and only on AMD Ryzen (znver2) and an old Intel i5 Haswell chip did this method help — and then it was only by about 20%.

Worse, this method is bugged for signed zeros; if the "wrong" signed zero is produced, then it re-runs the entire reduction (but without calling f) to see if the "right" zero should be returned.

Fixes #45932, fixes #36412, fixes #36081.

[giordano]

Worse, this method is bugged for signed zeros; if the "wrong" signed zero is produced, then it re-runs the entire reduction (but without calling f) to see if the "right" zero should be returned.

Sounds like that'd make a good test (if not there already)?

[mikmoore]

Looks like this eliminates some of the anti-performance specializations cited in #45581. Thanks!

[mbauman]

Yeah, looks like this is better than the naive loop #36412 suggested, too:

julia> function f_minimum(A::Array{<:Integer})
           result = A[1]
           @inbounds for i=2:length(A)
               if A[i] < result
                   result = A[i]
               end
           end
           return result
       end
f_minimum (generic function with 1 method)

julia> x = rand(Int, 10_000);

julia> using BenchmarkTools

julia> @btime minimum($x)
  3.057 μs (0 allocations: 0 bytes)
-9222765095448017038

julia> @btime f_minimum($x)
  1.613 μs (0 allocations: 0 bytes)
-9222765095448017038

julia> @btime reduce((x,y)->min(x,y), $x)
  1.450 μs (0 allocations: 0 bytes)
-9222765095448017038

[giordano]

Similarly to #58280, I'm not familiar with the reduction stuff but deleting code and getting correct results (with tests) and getting better performance looks a no-brainer yes to me

[oscardssmith]

On 11th gen intel, I see a much smaller, but still real performance win. It's likely worth noting for posterity that on 1.11 and older, the generic method is ~5x slower. I believe #56371 is what makes this PR an improvement rather than a massive regression.

[mbauman]

Consistent with what @oscardssmith notes, this PR sees the big perf improvement on v1.12 but is relatively perf-neutral on v1.11 and v1.10 on my M1 arch. Marking for backport to 1.12 given that it also fixes some bugs.