Optimize sort_by_key (SortFaces/SortVerts)

[stephomi]

Remap boxes separately

MacOS M1/TBB: 1485ms -> 1385ms

[codecov]

Codecov Report

Patch coverage: 100.00% and no project coverage change.

Comparison is base (2aef6e4) 90.23% compared to head (fc48069) 90.23%.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #494   +/-   ##
=======================================
  Coverage   90.23%   90.23%           
=======================================
  Files          35       35           
  Lines        4391     4391           
=======================================
  Hits         3962     3962           
  Misses        429      429           

Impacted Files	Coverage Δ
src/manifold/src/sort.cpp	89.14% <100.00%> (ø)

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[pca006132]

interesting, I guess these recent optimizations means that sort_by_key and sort using zip iterators are very slow? I originally thought that the performance should be fine.
will have a look more carefully later today

[stephomi]

Nah sort_by_key is fine. Actually you could use sort_by_key in my previous PR and it would give similar performance.

The only thing that matters is the size of the object to move (both keys or values), here by sorting boxes we are moving big objects an unnecessary amount of time.
If you plan on sync-sorting multiple array it’s best to to perform the sort on the minimal amount of memory and re-index the rest once.

[pca006132]

For the build error, I think we hit the #460. The safer way I can now think of is to use clang. Try to add the following commit:

diff --git a/flake.nix b/flake.nix
index 04ffc90..4c37ab3 100644
--- a/flake.nix
+++ b/flake.nix
@@ -16,7 +16,7 @@
             , doCheck ? true
             , build-tools ? [ ]
             , ...
-            }: pkgs.stdenv.mkDerivation {
+            }: pkgs.llvmPackages_15.stdenv.mkDerivation {
               inherit doCheck;
               pname =
                 if cuda-support then

Not sure if I'm breaking the whole CUDA thing though, if I don't get the pointer first, it just takes forever (unless I capture by reference [&] instead of value [=])

it seems that this is no longer relevant?

MacOS M1/TBB: 1485ms -> 1385ms

Wondering what benchmark are you using? Wonder if you can share them to the unit tests? This can help us track performance later.

[stephomi]

it seems that this is no longer relevant?

Yep, removed the comment to avoid confusion

Wondering what benchmark are you using? Wonder if you can share them to the unit tests? This can help us track performance later.

A simple sphere/cylinder subtraction.

I'm always benching the part that I'm editing, since there's a bit of variance by looking at the whole thing.
For the PR I'm giving timing difference for the whole operation to give an idea of the gain (minor here).

The part in question:

	Master	PR
SortVerts 1	22 ms	17 ms
SortVerts 2	4 ms	3 ms
SortVerts 3	20 ms	14 ms
SortFaces 1	100 ms	60 ms
SortFaces 2	15 ms	10 ms
SortFaces 3	97 ms	56 ms