pow is bottleneck, use faster pow!

[SimonDanisch]

Since the algorithm doesn't seem to need much precision, it works out pretty well:

It's 2.5x faster with fast_pow
if the loss in precision isn't acceptable ( i think it's a pretty rough approximation), ironically removing @fastmath also speed things up, since then it uses llvm.pow, which seems to optimize better!

[codecov-io]

Codecov Report

Merging #2 into master will increase coverage by 2.63%.
The diff coverage is 84.21%.

@@            Coverage Diff            @@
##           master      #2      +/-   ##
=========================================
+ Coverage   83.76%   86.4%   +2.63%     
=========================================
  Files           3       3              
  Lines         117     125       +8     
=========================================
+ Hits           98     108      +10     
+ Misses         19      17       -2

Impacted Files	Coverage Δ
src/umap_.jl	85.59% <84.21%> (+2.86%)	⬆️

---

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 eb740f6...7f2bfa7. Read the comment docs.

[SimonDanisch]

Interestingly, the speed up is much less pronounced when using the full dataset (benchmarked on only a small portion)... Guess then the nearest neighbor becomes more expensive.

[dillondaudert]

Thanks for making this PR!

I plan on doing some profiling to get a sense of how costly each component (including pow) is overall. It'd be nice to get a comparison of the three options you mention (current implementation, without @fastmath, and with fast_pow. I also have some more general thoughts.

I took a look at the source of fast_pow and one thing that doesn't sit well with me is that it doesn't seem rigorously tested, in the sense that the performance and error characteristics aren't really known (and therefore impossible to reason about). It's true SGD has tolerance for noise but it seems risky, I'll have to think about the potential impact more.

Another thing I'm wondering about is if the implementation of this function should reside in UMAP.jl itself. I haven't looked, but there might be a numerical methods-related package that is more appropriate (which we could then import from).

[dillondaudert]

@fastmath has been removed (f61ad40), which shaved about 20 seconds off the MNIST example runtime when I tested it.

[dillondaudert]

Had a look at the R implementation of UMAP today, looks like they use the same approximate power here - enabled by a keyword arg. It seems acceptable to me to incorporate it in a similar way here.