-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Partially revert "Remove specialized sort! method for PartialQuickSort{Int} (fixes #12833)" #31632
Partially revert "Remove specialized sort! method for PartialQuickSort{Int} (fixes #12833)" #31632
Conversation
Can't quite tell of the Linux32 test run failure is of concern or not. cc @staticfloat |
Hmm, a stack overflow during the |
Should nanosoldier be run on this? Otherwise should be good to go. |
e4f8e6a
to
a3803da
Compare
Rebased to incorporate #31693. |
Travis error was a DNS problem ( The buildbot error was the same error I got on OSX here, so it is probably a recently introduced bug.
Link in case it gets rerun: https://build.julialang.org/#/builders/13/builds/1602 |
a3803da
to
865a09c
Compare
…t{Int} (fixes JuliaLang#12833)" This reverts commit 9e8fcd3, except for the test. The underlying issue(s) causing JuliaLang#12833 seem to have been fixed with recent changes in inference.
865a09c
to
58d7769
Compare
32-bit AppVeyor build failed on a DNS lookup. Can someone please restart it? (Cc: @staticfloat @ararslan) Everything else has passed. |
Restarted. |
Another (seemingly unrelated) error.
|
Sounds like #29880. The Windows buildbot passed, so I think the issue is just AppVeyor being weird and can be safely ignored here. |
👍 |
This specialized method is actually considerably slower than the one that also works for `PartialQuickSort{<:OrdinalRange}`. It had been removed before in 9e8fcd3 due to an inference issue, and reintroduced by c41d5a3 (#31632) once that issue got fixed, but apparently without benchmarks. It turns out that saving one comparison per iteration isn't worth it. The gain is especially large when sorting a value close to the end of the vector, as the specialized method always sorted all values lower than the requested one.
This specialized method is actually considerably slower than the one that also works for `PartialQuickSort{<:OrdinalRange}`. It had been removed before in 9e8fcd3 due to an inference issue, and reintroduced by c41d5a3 (#31632) once that issue got fixed, but apparently without benchmarks. It turns out that saving one comparison per iteration isn't worth it. The gain is especially large when looking for a value among the largest in the array, as the specialized method always sorted all values lower than the requested one.
This specialized method is actually considerably slower than the one that also works for `PartialQuickSort{<:OrdinalRange}`. It had been removed before in 9e8fcd3 due to an inference issue, and reintroduced by c41d5a3 (#31632) once that issue got fixed, but apparently without benchmarks. It turns out that saving one comparison per iteration isn't worth it. The gain is especially large when looking for a value among the largest in the array, as the specialized method always sorted all values lower than the requested one.
This specialized method is actually considerably slower than the one that also works for `PartialQuickSort{<:OrdinalRange}`. It had been removed before in 9e8fcd3 due to an inference issue, and reintroduced by c41d5a3 (#31632) once that issue got fixed, but apparently without benchmarks. It turns out that saving one comparison per iteration isn't worth it. The gain is especially large when looking for a value among the largest in the array, as the specialized method always sorted all values lower than the requested one.
This specialized method is actually considerably slower than the one that also works for `PartialQuickSort{<:OrdinalRange}`. It had been removed before in 9e8fcd3 due to an inference issue, and reintroduced by c41d5a3 (#31632) once that issue got fixed, but apparently without benchmarks. It turns out that saving one comparison per iteration isn't worth it. The gain is especially large when looking for a value among the largest in the array, as the specialized method always sorted all values lower than the requested one.
This reverts commit 9e8fcd3, except for the
test. The underlying issue(s) causing #12833 seem to have been fixed with recent
changes in inference.