Optimize Radix sort.

[shreyas-omkar]

CUDA (RTX 5080), 4M elements

Type	AK radix (ms)	torch.sort (ms)	AK / torch
UInt32	1.11	0.49	2.25×
Float32	1.12	0.49	2.31×
UInt64	1.85	1.35	1.37×
Float64	1.68	1.33	1.27×

AMD (RX 9060 XT), 4M elements

Type	AK radix (ms)	torch.sort (ms)	AK / torch
UInt32	2.74	1.83	1.50×
Float32	2.76	1.75	1.58×
UInt64	5.70	5.84	0.98×
Float64	5.84	4.43	1.32×

[christiangnrd]

Current OpenCL sort failures seem to be related (or surfaced by) radix sort. On my device, it hangs when julia isn't launched with --check-bounds=yes

MWE:

using pocl_jll, OpenCL; import AcceleratedKernels as AK; begin
v_arr = rand(Int32, 68931)
v = CLArray(v_arr);
@info "Sorting"
AK.sort!(v; alg=AK.RadixSort())
@info "Sorted"
issorted(Array(v))
end

This is probably POCL since this MWE passes on the Asahi driver

[shreyas-omkar]

histogram completes fine. AK.accumulate hangs for n > 512. Fix is pushed. Can you test the repro once on Mac?

[shreyas-omkar]

@christiangnrd and @maleadt Please review it.

[maleadt]

Reviewed and tightened this a little:

• Floating-point ordering now matches Base, including negative NaNs, signed zero, infinities, and reverse sorting.
• Radix sort now composes rev and order like Base does. In particular, rev=true, order=Reverse correctly gives ascending order.
• Unsupported custom orderings now fail clearly instead of silently sorting by the wrong ordering.
• Tuning is available through RadixSort(block_size=..., items_per_thread=...).
• Configurations that would exceed Metal’s shared-memory limit use the portable path instead of failing kernel compilation.

I also removed the tile abstraction for now; it was pretty unused here. I'd prefer if we land this separately (porting more from GemmKernels.jl's abstraction like the 2D support, and adapting multiple algorithms here to validate the design).

Validated on OpenCL.jl and Metal.jl. Performance improvements are real, so this is looking good.

[maleadt]

OpenCL.jl fixed in JuliaPackaging/Yggdrasil#14480, CUDA.jl failure is JuliaConcurrent/UnsafeAtomics.jl#23.

[maleadt]

Hm, I can't reproduce the oneAPI failure. In any case, looks unrelated to this branch.