# Julia motivation: why weren't Numpy, Scipy, Numba, good enough?

**URL:** <https://discourse.julialang.org/t/julia-motivation-why-werent-numpy-scipy-numba-good-enough/2236>\
**Category:** Community\
**Tags:** history\
**Created:** [February 22, 2017, 3:34pm UTC](https://discourse.julialang.org/t/julia-motivation-why-werent-numpy-scipy-numba-good-enough/2236 "2017-02-22T15:34:33Z")\
**Posts on this page:** 1\
**Showing post:** 20

<div class="post-metadata">

**Author:** ![ChrisRackauckas](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/chrisrackauckas/32/77_2.png) [@ChrisRackauckas](https://discourse.julialang.org/u/ChrisRackauckas)\
**Post date:** [February 23, 2017, 4:54pm UTC](https://discourse.julialang.org/t/julia-motivation-why-werent-numpy-scipy-numba-good-enough/2236/20 "2017-02-23T16:54:14Z")

</div>

> [@RoyiAvital](#):
>
> Going forward, do you think it is achievable, in the future, to write code in its Vectorized Form + Decorations in Julia and have performance of highly optimized (SIMD + Threading) C Code?

The very simple answer is, if you use the `-O3` flag, then the compiler already automatically will use SIMD when appropriate (try a simple loop. Make sure you’ve re-built the system image or made Julia from the source). As for adding threading, the answer looks like it will be some macro (and you know about this since you’ve commented in the issue):

> <https://github.com/JuliaLang/julia/issues/19777>
>
> It would be nice to be able to put \`@threads\` in front of a dot call, e.g. \`@thr…eads X .= f.(Y)\`, and have it call a multi-threaded version of \`broadcast\` (which would assume \`f\` is thread-safe).

But…

> [@RoyiAvital](#):
>
> I’m talking about the core language and core language in my point of view is arrays and the basic math operations (In Multi Dimensional Space, Like Linear Algebra).

> [@RoyiAvital](#):
>
> It has nothing to do with packages and please don’t refer me to those.

What I am trying to get across is that those things will actually be packages. There are already many discussions about how to move the linear algebra parts out to a package, and it looks like it will be done before 1.0 ([it’s waiting on the implementation of a system for default packages](https://github.com/JuliaLang/julia/issues/18795)). Even the basic math functions like `sqrt`: Julia currently uses a version of OpenLibm, but there are some very advanced experiments with Julia implementations like Libm.jl and Amal.jl for replacing all of this basic math with packages (some packages may be loaded by default, but they will still just be packages).

So what I am really trying to hammer home is that the idea that “no it’s not Julia if it’s a package, let’s only talk about ‘Julia’” as though there is some privileged Base Julia which rules above all others: that idea is very wrongheaded. I think it’s safe to say that very soon, all of what you think of as “basic math operations” will be “default packages”: just standard Julia packages which by default are loaded into the system image.

> [@RoyiAvital](#):
>
> It has nothing to do with packages and please don’t refer me to those.I’m asking about the concept of Julia.

So yes, even your examples of what do not refer to packages, actually refer to what will be packages. That means I think it’s safe to say you cannot talk about Julia as though it’s isolated from its package ecosystem. I think at this point, the concept of Julia includes packages, as seen by how things which were considered essential enough to be in early Julia have now moved out into packages. In that sense, you can already do what you’re asking in Julia using ParallelAccelerator, and the equivalent to Python+Numba in Julia is actually Julia+ParallelAccelerator.

> [@swissr](#):
>
> Isn’t it getting a bit offtopic now? I appreciated the discussion related to Python. - Maybe the posts starting with “Going forward, do you think it is achievable, in the future, to write code in its Vectorized Form + Decorations in Julia and have performance of highly optimized (SIMD + Threading) C Code?” could be splitted into its own thread?

Yes, that question hijacks the thread and all responses after it should be a separate thread about the future of auto-optimizing (SIMD, multi-threading, etc.) Julia code. Auto-optimizing Julia code a la Numba is something related to “making Julia fast”, but in some sense that is more about making Julia match hardware, not the design of Julia itself and why it makes sense as a way to specify scientific programs.

---

_[View the full topic](https://discourse.julialang.org/t/julia-motivation-why-werent-numpy-scipy-numba-good-enough/2236)._