[All] Replace qsort with faster std sort

[noelchalmers]

No description provided.

[codecov]

Codecov Report

Merging #62 (298a092) into master (2a92cad) will decrease coverage by 0.03%.
The diff coverage is 89.30%.

@@            Coverage Diff             @@
##           master      #62      +/-   ##
==========================================
- Coverage   84.76%   84.73%   -0.04%     
==========================================
  Files         251      251              
  Lines       19932    19897      -35     
==========================================
- Hits        16896    16859      -37     
- Misses       3036     3038       +2     

Impacted Files	Coverage Δ
...s/elliptic/src/ellipticBuildOperatorMatrixIpdg.cpp	67.07% <66.66%> (-0.01%)	⬇️
...ptic/src/ellipticBuildOperatorMatrixContinuous.cpp	80.58% <80.00%> (-0.43%)	⬇️
libs/parAlmond/parAlmondparCSR.cpp	91.03% <87.50%> (+1.07%)	⬆️
libs/mesh/meshConnect.cpp	100.00% <100.00%> (+3.84%)	⬆️
libs/mesh/meshConnectBoundary.cpp	100.00% <100.00%> (ø)
libs/mesh/meshHaloRingSetup.cpp	100.00% <100.00%> (ø)
libs/mesh/meshParallelConnectOpt.cpp	100.00% <100.00%> (+1.62%)	⬆️
libs/ogs/ogsSetup.cpp	98.66% <100.00%> (+0.95%)	⬆️
libs/parAlmond/parAlmondGalerkinProd.cpp	100.00% <100.00%> (ø)
libs/parAlmond/parAlmondSmoothPrologator.cpp	100.00% <100.00%> (ø)
... and 2 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2a92cad...298a092. Read the comment docs.

[tcew]

Does this noticeably speed up preprocessing ?

I found mixed results when experimenting with std::sort for matrix assembly.

[noelchalmers]

It probably takes pretty big sorts to notice a major difference. At least with std::sort the compiler has more opportunity for optimizations. Even if it's similar in runtime, I find the syntax with passing the comparison function as a lambda to be more clear than having a bunch of static comparison functions laying around.

[tcew]

Two things to contemplate:

1. It adda one more set of C++ concepts for students to grasp.

2. Eventually I think we should move all the preprocessing stuff on device, including the sort based topology methods. This will be important for adaptivity, remeshing, & moving mesh stuff where topology changes frequently. The standard library sort is not portable for on device and I have reservations about importing thrust or similar given their complexity.

I was able to refactor matrix assembly to avoid global sorts - perhaps we can do something smarter with topology too?

[noelchalmers]

I agree with your comments, lambda syntax is bizarre when you first see it. But that aside, I still find the std::sort syntax cleaner and more flexible than qsort since we can explicitly pass in the comparison function rather than a function pointer declared elsewhere and having to type cast a bunch of void*s. If anything this will be more akin to how we would make a device sort routine, by passing a .okl comparison function as a string.

And, of course, this may all be moot later as we move more things to the device and replace std::sort instances.

I'm not welded to this change, you can have final say. If you're ok with it, feel free to merge, otherwise you can close.

[tcew]

I’ll merge it given that this will mostly be replaced by on device sorts. Setting up a flexible device sort would be a good step forward.

I strongly recommend avoiding going further the down the C++ rabbit hole. Using iterators comes to mind as one trap that will make it tricky to offload.