Performance of `gradient1`

[cortner]

I've just benchmarked the performance of cubic B-splines on an M1 with the following results:

[ Info: Performance of evaluation
  8.717 ns (0 allocations: 0 bytes)
[ Info: Performance of gradient
  56.682 ns (0 allocations: 0 bytes)

I am struck by the discrepancy. The cost of the derivative should be comparable or less than the cost of the evaluation. Even for relatively complex scalar function evaluations, the derivative should be at most a factor-2.

Not having contributed to this package before I'm unsure about my ability to look into this myself but I'm open to it in principle. Still I'd be interested to hear the developers' thoughts on this.

[cortner]

.... indeed as I'm writing this it occured to me that ForwardDiff will probably get very good performance:

[ Info: And with FOrwardDiff
  14.570 ns (0 allocations: 0 bytes)

[mkitti]

Could you provide the code that generated the benchmark?

[cortner]

trying to reduce it to a short script, the weirdest thing happened:

using Interpolations, ForwardDiff 
rr = range(0.0, stop=5.0, length=10_000)
spl = cubic_spline_interpolation(rr, sin.(rr))
r = rand() * 5
print("Evaluation: "); @btime $spl($r)
print(" gradient1: "); @btime Interpolations.gradient1($spl, $r)
print("      Dual: "); @btime $spl(ForwardDiff.Dual($r, 1))

rr = range(0.0, stop=5.0, length=10_000)
spl = cubic_spline_interpolation(rr, sin.(rr))
r = rand() * 5
@btime $spl($r)
@btime Interpolations.gradient1($spl, $r)
@btime $spl(ForwardDiff.Dual($r, 1))

produces output

Evaluation:   8.717 ns (0 allocations: 0 bytes)
 gradient1:   12.345 ns (0 allocations: 0 bytes)
      Dual:   15.030 ns (0 allocations: 0 bytes)
  8.717 ns (0 allocations: 0 bytes)
  56.682 ns (0 allocations: 0 bytes)
  15.030 ns (0 allocations: 0 bytes)

Most likely a problem with benchmarking and not with Interpolations.jl, please close this if you agree.

[mkitti]

Try running with @benchmark to get more statistics.

[cortner]

with @benchmark the discrepancy does not occur. If you agree, we close this and I file an issue with BenchmarkTools

[mkitti]

That is intriguing. How so?

@btime reports the fastest time. @benchmark obviously provides more statistics. Perhaps more autodiff is occurring on the first run than the second run?

[cortner]

that would not explain it. The weird time is already the second run.

[mkitti]

Is the weird time the faster time?

[cortner]

No - the slow time. The fast time is consistent with what I'm expecting to see.

[cortner]

I cannot reproduce in latest versions.