Evolve to in-place sorting

[mark-kubacki]

Now that histogram and watermark(s) are one (#4), I see the opportunity to further evolve this into (state of the art) in-place sorting.

Would you entertain a PR or do you want to keep the current algorithm?

[shawnsmithdev]

I'm kind of waiting on what happens with generics. If it is performant enough, I'm just going to start a v2 and clean out the duplicate code. If not then I'll probably keep things as is, with all the copied code. Either way I'm not willing to spend a whole lot of effort on something that works fairly well at the moment until we get some clarity there.

[shawnsmithdev]

That being said, have at it. I'd be fascinated to see an in-place radix sort in Go, even if it's just for uint64. I read some stuff on it several years ago when I first started working on zermelo, but I was never able to get it to work back then.

edit: We can just call this v2, and punt on if it will be generic or not.

[mark-kubacki]

No need to make it a v2, the public interface won't change.

AMD's memory access predictor will interfere more on this one, so I'm not sure whether this will net a substantial gain. I expect a small one, though, as we get to utilize caches better.

I'm doing this out of curiosity, with no deadline in mind. Brilliantly enough I've closed my browser tab with the paper—don't expect any PR until end of the month or Dec.

[shawnsmithdev]

This would need to be enough of an improvement to be worth the additional code complexity. The important platforms I am targeting for this library are x86_64 (both intel and amd) on linux and win64 and mac, and also arm64 on linux (and eventually mac when that is a thing).

But yes you are right, if it works out and doesn't change the API we won't need a new major version.

[shawnsmithdev]

Created a new issue for generics; this issue is now specifically about in-place radix sort.