# Could this simple function go faster?

**URL:** <https://discourse.julialang.org/t/could-this-simple-function-go-faster/50034>\
**Category:** Performance\
**Created:** [November 12, 2020, 8:27am UTC](https://discourse.julialang.org/t/could-this-simple-function-go-faster/50034 "2020-11-12T08:27:01Z")\
**Posts on this page:** 1\
**Showing post:** 13

<div class="post-metadata">

**Author:** ![lrnv](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lrnv/32/19373_2.png) [@lrnv](https://discourse.julialang.org/u/lrnv)\
**Post date:** [November 12, 2020, 3:27pm UTC](https://discourse.julialang.org/t/could-this-simple-function-go-faster/50034/13 "2020-11-12T15:27:25Z")

</div>

> [@stevengj](#):
>
> The basic issue here is that, for `BigFloat` and `BigInt` (“bignum”) calculations, the arithmetic cost will typically dominate any algorithm. Almost all that matters is probably the number of bignum operations. Type stability, allocation of temporary arrays, and all of the other usual Julia considerations are likely to have relatively small impact. So, you need to focus on algorithmic improvements that reduce the number of arithmetic operations.

This is clearly an issue. I could do more precomputations to replace `prod(P.BINS[CartesianIndex.(k_minus_one_in_deg,j_arr)])`, which demands `n` product of bigfloats by only one indexing, but it gave me an OutOfMemory error if i want to cover all cases upfront 😉

What about [GitHub - JuliaArbTypes/ArbFloats.jl: Much faster than BigFloat at precisions up to 3,500 bits (1050 digits)](https://github.com/JuliaArbTypes/ArbFloats.jl) ?

---

_[View the full topic](https://discourse.julialang.org/t/could-this-simple-function-go-faster/50034)._