Reimplement linear methods using recursive method

[jlogan03]

0.4.3 - 2024-08-03

Added

• Implement interpn_alloc function for each method, which allocates a Vec for the output
• Add test of linear methods using hat function to check grid cell alignment

Changed

• Use recursive method to evaluate multilinear interpolation instead of hypercube method
  • This makes extrapolation cost consistent with interpolation cost, and reduces nominal perf scaling
  • Shows about 2x slower perf in micro-benchmarks, but about 2x faster in end-to-end benchmarks after the Python bindings
    • Need to improve benchmarking strategy to better capture perf in real-life usage
• Reduce repeated documentation
• Remove some inlining annotations and all instances of #[inline(always)]
  • Minimal effect on performance; provides more flexibility to downstream applications, especially opt-level=s builds

---

end-to-end linear method perf scaling before (on linux/amd desktop machine)

after (on linux/amd framework laptop):

[obi1kenobi]

I would strongly advise against using inline(always) in general. More details inline.

Also, be careful of having complex inlined methods in generics. After monomorphization, you might end up with a ton of copies of those complex methods in your executable. That'll bloat the binary size, drag out compile times, and probably result in worse performance because bigger binaries are just slower due to their own instructions' cache pressure.

See e.g. https://twitter.com/charliermarsh/status/1819873110448820668 for an example of monomorphization causing bloat.

[obi1kenobi]

You probably don't want inline(always) here. In fact inline(always) is probably best avoided pretty much always.

Inlining in LLVM happens "leaves-first", which is backwards from how most of our intuition would expect it to happen. The LLVM inliner on its own would probably decide to inline the ::new() call and the .interp() call into this function.

Then the #[inline(always)] will force it to inline this function into all call sites, and you'll end up with the contents of MulticubicRectilinear::new() and MulticubicRectilinear::interp() inlined all over the place separately. That's probably not desirable.

[jlogan03]

Good point - each instance of inlining directives in here was originally checked in criterion benchmarks, but I'm finding lately that the benchmarks end up compiled somewhat differently from downstream usages. I'll check how it looks in end-to-end benchmarks via the python bindings with more reasonable inlining annotations.

[jlogan03]

The perf gains from gratuitous inlining do appear to be an artifact of benchmarking. This snip (benchmarks running after switching from less-inlined version of both linear calcs back to unmodified) would indicate a significant perf regression for the specific case of evaluating one point at a time, which is an important case for differentiation:

However, end-to-end benchmarks through the python bindings do not show any significant degradation for the case of 1 observation point:

[jlogan03]

The rectilinear method doesn't show any significant change here, possibly because the core library bisection search is fairly low in the inlining tree, and is marked inline(never)

[jlogan03]

No identifiable change in end-to-end benchmarks in python after removing all inlining annotations, even for the single-observation-point cases that see 2x slowdown in rust benchmarks. This should help embedded usages as well, since opt-level=s builds will behave more as expected

[jlogan03]

Re: monomorphization bloat - definitely a thing that I think about. In this case, the only generics are on the data type and max dimensionality. The only types in common use that implement Float are f32 and f64 in core, plus f16 and f128 available in crates, and I don't anticipate seeing many uses of MAXDIMS other than the default of 8 since that's already an unreasonably large number of dimensions and doesn't affect perf noticeably.

[obi1kenobi]

I think #[inline] is fine if you have leaf code you expect to be hot. It's really just #[inline(always)] especially on large non-leaf functions that ends up being problematic.

[jlogan03]

Agreed - in this case, having just #[inline] doesn't produce any change in performance (even in the hypersensitive micro benchmarks), probably because the hot leaf functions are already small enough that they get inlined without adjusting the weights. So, might as well remove the manual annotations and just leave it to the compiler

[jlogan03]

Thinking about this a little more - even in an opt-level=s build, you'd still want those functions to inline because they're tiny and the effect on perf would be really punishing if they didn't get inlined. So I'll sprinkle a few #[inline] back in there just in case

[jlogan03]

Sprinkled some #[inline] on the chain of functions at the very bottom of the recursion for each interpolator type. No effect on benchmarks at all at opt-level=3, but might help keep something silly from happening in a different build someday