# How hard would it be to implement Numpy.jl, i.e. Numpy in Julia?

**URL:** <https://discourse.julialang.org/t/how-hard-would-it-be-to-implement-numpy-jl-i-e-numpy-in-julia/22080>\
**Category:** Numerics\
**Tags:** faq, python\
**Created:** [March 19, 2019, 10:48pm UTC](https://discourse.julialang.org/t/how-hard-would-it-be-to-implement-numpy-jl-i-e-numpy-in-julia/22080 "2019-03-19T22:48:54Z")\
**Posts on this page:** 1\
**Showing post:** 67

<div class="post-metadata">

**Author:** ![sdanisch](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/sdanisch/32/1406_2.png) [@sdanisch](https://discourse.julialang.org/u/sdanisch)\
**Post date:** [April 20, 2019, 12:04pm UTC](https://discourse.julialang.org/t/how-hard-would-it-be-to-implement-numpy-jl-i-e-numpy-in-julia/22080/67 "2019-04-20T12:04:42Z")

</div>

The reason for the 12x speed difference has been explained multiple times and is very simple: if you dont use the `sin` compiler intrinsic, any of the used compilers wasn’t able to infer that `sin` is pure and therefore doesn’t hoist it out of the loop… Btw, Wolf also run into that when he tried to use xsimd::sin 😉 Julia’s `sin` is implemented in pure Julia, which makes it have that problem by default, but is also easily solvable by calling into the llvm `sin` intrinsic.

---

_[View the full topic](https://discourse.julialang.org/t/how-hard-would-it-be-to-implement-numpy-jl-i-e-numpy-in-julia/22080)._
