New package: OptimalSortingNetworks v1.0.0

[JuliaRegistrator]

• Registering package: OptimalSortingNetworks
• Repository: https://gitlab.com/nsajko/OptimalSortingNetworks.jl
• Created by: https://gitlab.com/nsajko
• Version: v1.0.0
• Commit: 689ffad4d222fb9ec21f16962308c90dcf1781a4
• Git reference: HEAD
• Description: Sort small collections efficiently and with good type inference. The sort is an
  unstable sort. The supported collections are currently tuples and vectors.

[github-actions]

Your new package pull request met all of the guidelines for auto-merging and is scheduled to be merged when the mandatory waiting period (3 days) has elapsed.

Since you are registering a new package, please make sure that you have read the package naming guidelines: https://julialang.github.io/Pkg.jl/dev/creating-packages/#Package-naming-guidelines-1

---

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment. You can edit blocking comments, adding [noblock] to them in order to unblock auto-merging.

[GunnarFarneback]

[noblock]
It may be worth saying something in the README how this package compares to the SortingNetworks package.

Can you give an example where Depth is faster than Size? It doesn't seem to be the case for plain Int, at least not on my computer. I imagine Int provides about as fast compare/exchange as you'll find.

julia> using OptimalSortingNetworks: sorted, Depth, Size

julia> using Random, BenchmarkTools

julia> x = tuple(randperm(10)...);

julia> @btime sorted($x, Depth())
  6.501 ns (0 allocations: 0 bytes)
(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)

julia> @btime sorted($x, Size())
  6.133 ns (0 allocations: 0 bytes)
(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)

[nsajko]

[noblock]

You're right, Size() is faster. The advantage of a network with less depth is supposed to be more potential for exploiting parallelism, but I guess the CPU simply doesn't have the capability for that much parallelism? Or maybe the compiler is just not doing a good-enough job? Perhaps a more SIMD-aware implementation could change things... Have to correct the doc strings now.

julia> using OptimalSortingNetworks, BenchmarkTools, Random

julia> function s!(v::AbstractVector, opt)
         for i ∈ 0:(length(v) - 1)
           v[begin + i] = sorted(v[begin + i], opt)
         end
       end
s! (generic function with 1 method)

julia> const OSN = OptimalSortingNetworks
OptimalSortingNetworks

julia> const opt_d = OSN.Depth()
OptimalSortingNetworks.Depth()

julia> const opt_s = OSN.Size()
OptimalSortingNetworks.Size()

julia> tup(::Val{n}) where {n} = (randperm(n)...,)
tup (generic function with 1 method)

julia> vect(::Val{n}, len) where {n} = [tup(Val(n)) for _ ∈ 1:len]
vect (generic function with 1 method)

julia> @btime s!(v, opt_d) setup=(v=vect(Val(10), 2000);)
  14.236 μs (0 allocations: 0 bytes)

julia> @btime s!(v, opt_s) setup=(v=vect(Val(10), 2000);)
  13.936 μs (0 allocations: 0 bytes)

julia> @btime s!(v, opt_d) setup=(v=vect(Val(10), 2000);)
  14.246 μs (0 allocations: 0 bytes)

julia> @btime s!(v, opt_s) setup=(v=vect(Val(10), 2000);)
  13.966 μs (0 allocations: 0 bytes)

[nsajko]

[noblock] @GunnarFarneback I tried to address your concerns with the latest changes.