sort handles incomparable values

[Akirathan]

Fixes #5742

Pull Request Description

Vector.sort handles incomparable values. Now, it should sort basically any vector, potentially attaching a warning if sort encountered incomparable values.

Important Notes

• Slight change of Vector.sort method signature
  • To be able to introduce Vector.sort_builtin optimized builtin for the most common case - sorting only primitive values with Default_Comparator.

Checklist

Please ensure that the following checklist has been satisfied before submitting the PR:

• The documentation has been updated, if necessary.
• Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
• All code follows the
  Scala,
  Java,
  and
  Rust
  style guides. In case you are using a language not listed above, follow the Rust style guide.
• All code has been tested:
  • Unit tests have been written where possible.
  • If GUI codebase was changed, the GUI was tested when built using ./run ide build.

[radeusgd]

I'll appreciate applying the two suggestions. Other than that - it all looks very good! I'm glad vector sort will be improved now. And I really appreciate very good unit tests.

[Akirathan]

Scheduled benchmarks in https://github.com/enso-org/enso/actions/runs/4702222179.

I have checked test/Benchmarks/src/Table/Sorting.enso benchmark locally, and all the benchmarks have better performance, except for "Table.order_by object", that regressed by 25%. That particular benchmark creates a lot of My atoms with a custom My_Comparator and are move into a table and order_by is called, which calls into Java and then back into Enso (in ObjectComparator). There is no simple solution how to make that faster in general, at least not now. I am not sure why there is such regression, though, and I am not going to investigate anymore now.

GitHub

Benchmark Engine · enso-org/enso@8268e02

Hybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.

[JaroslavTulach]

• Use alter in the Vector_Spec.enso
• Don't forget to convert interop values with HostToEnsoValueNode

[JaroslavTulach]

Without this import we cannot use <= anymore.

• result of 0df66b1
• also reported as Comparison operators should not require importing Standard.Base.Any module #5610

[Akirathan]

Benchmark results

Baseline from develop:

• https://github.com/enso-org/enso/actions/runs/4684019136
• On commit 4e92d76

I had to revert 0df66b1 ("Remove the remaining comparison operator overrides for numbers"), as that caused a huge performance regressions on benchmarks dealing with vectors with primitive values. This commit was not essential for this PR, and we can deal with it later.

After the revert, I tried running and comparing some benchmarks locally. Comparison of my recent version (254d579) with the baseline is:

• test/Benchmarks/src/Table/Sorting.enso:
  • Table.order_by ints: -5% (means -5% milliseconds, so it is better 5% better than before)
  • Vector.sort ints: -5%
  • Table.order_by_dates: -7%
  • Vector.sort dates -36%
  • Table.order_by objects +1%
  • Vector.sort objects -64%
• Benchmarks from org.enso.interpreter.bench.benchmarks.semantic.ArrayProxyBenchmarks stayed roughly the same, with one exception of:
  • sumOverVector that got +40%. I have no idea why, the changes in this PR should not affect that benchmark. Tried to look into the Truffle compilation logs and did not discovered anything interesting. I will let this one go now.

Conclusion

Overall, the benchmark results seem pretty good. Sorting of vector with primitive values is roughly the same, but we can see huge improvements for sorting of vector with some atoms (-64%) and dates (-36%). Will merge this PR ASAP.

GitHub

Benchmark Engine · enso-org/enso@4e92d76

Hybrid visual and textual functional programming. Contribute to enso-org/enso development by creating an account on GitHub.