Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add non-allocating sort function to libcore #19221

Closed
mahkoh opened this issue Nov 22, 2014 · 4 comments
Closed

Add non-allocating sort function to libcore #19221

mahkoh opened this issue Nov 22, 2014 · 4 comments
Labels
A-collections Area: std::collections. C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@mahkoh
Copy link
Contributor

mahkoh commented Nov 22, 2014

No description provided.

@kmcallister kmcallister added C-enhancement Category: An issue proposing an enhancement or a PR with one. A-libs labels Nov 23, 2014
@veddan
Copy link
Contributor

veddan commented Nov 26, 2014

I have a #[no_std] introsort implementation at veddan/rust-introsort. It's faster than the standard sort for all inputs I can find, and is significantly faster if the input is partially sorted or has few unique values. One temporary issue is that, unlike the merge sort in std, the comparison function fails to inline with old-style closures. Therefore it uses unboxed closures and has a different signature than std's sort_by.

Maybe the non-allocating sort function in core can be re-exported in std as unstable_sort or something similar?

@thestinger
Copy link
Contributor

It would be interesting to try out one of the bleeding edge in-place merge sort algorithms:

There's no reason not to have high performance, stable sorting and no allocation.

@kmcallister kmcallister added the A-collections Area: std::collections. label Jan 16, 2015
@Gankra
Copy link
Contributor

Gankra commented Jan 19, 2015

I started looking into this. GrailSort is a bit faster for some inputs (by the Wikisort author's own claim), but WikiSort is considerably better documented (and public domain!). As such it seems like the more promising algorithm to duplicate.

That said, it's complex. An optimized Wikisort involves an implementation of insertion sort, vanilla merge sort, sorting networks (with side-tables for stability), and of course the actual wikisort algorithm. All in all the impl ends up being about 900 lines of well-documented C++ code. Not insane, but not a walk in the park, either.

@steveklabnik
Copy link
Member

I'm pulling a massive triage effort to get us ready for 1.0. As part of this, I'm moving stuff that's wishlist-like to the RFCs repo, as that's where major new things should get discussed/prioritized.

This issue has been moved to the RFCs repo: rust-lang/rfcs#790

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-collections Area: std::collections. C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

6 participants