Support `mapreduce` with multiple source arrays

[christiangnrd]

In GPUArrays, this is implemented with broadcasting. This will probably require a breaking release since the backend argument will no longer be able to be the last argument.

julia> import AcceleratedKernels as AK; a = ones(5); b = ones(5);

julia> mapreduce(+,+,a,b)
10.0

julia> AK.mapreduce(+,+,a,b; init=0)
ERROR: MethodError: no method matching mapreduce(::typeof(+), ::typeof(+), ::Vector{Float64}, ::Vector{Float64}; init::Int64)
You may have intended to import Base.mapreduce
The function `mapreduce` exists, but no method is defined for this combination of argument types.

Closest candidates are:
  mapreduce(::Any, ::Any, ::AbstractArray, ::KernelAbstractions.Backend; init, kwargs...)
   @ AcceleratedKernels ~/.julia/packages/AcceleratedKernels/xxjhi/src/reduce/reduce.jl:156
  mapreduce(::Any, ::Any, ::AbstractArray; ...)
   @ AcceleratedKernels ~/.julia/packages/AcceleratedKernels/xxjhi/src/reduce/reduce.jl:156

Stacktrace:
 [1] top-level scope
   @ REPL[10]:1
 [2] top-level scope
   @ ~/.julia/dev/Metal/src/initialization.jl:80
end

[anicusan]

What is the exact usecase for this? Mainly feature-parity with GPUArrays?
I think we could still make it work with backend being the last positional argument, albeit with a less elegant args[end] isa Backend check (or something of the sort).

[christiangnrd]

What is the exact usecase for this? Mainly feature-parity with GPUArrays?

Yes. See JuliaGPU/GPUArrays.jl#607 for some thoughts. I was able to get it working by materializing before passing to AcceleratedKernels, but there's probably a noticeable performance impact from this.

I think we could still make it work with backend being the last positional argument, albeit with a less elegant args[end] isa Backend check (or something of the sort).

I wonder what the performance impact of this would be.

[maleadt]

This will probably require a breaking release since the backend argument will no longer be able to be the last argument.

That seems like a questionable API regardless; what about making it a obligatory keyword argument?

[anicusan]

Why is it questionable to have backend as a positional argument?

In terms of performance, tuples are heterogeneously-typed containers - types are known at compile time, and we can do type-based filtering (again at compile time, because Julia magic); so in terms of performance there should be zero overhead. But I do care about the interface a lot, and your opinions @christiangnrd @maleadt are very valuable :)

[maleadt]

Why is it questionable to have backend as a positional argument?

Because it restricts the API as demonstrated here, where extending beyond one positional argument is very reasonable. Personally I try to only use "special" positional arguments when in first position (e.g. resize!(::Array, dims...)), or else put them in a keyword argument which has the added benefit of self-documenting the purpose.