# Ensure Julia is used to its full power

**URL:** <https://discourse.julialang.org/t/ensure-julia-is-used-to-its-full-power/51155>\
**Category:** New to Julia\
**Tags:** question, first-steps\
**Created:** [December 3, 2020, 12:02am UTC](https://discourse.julialang.org/t/ensure-julia-is-used-to-its-full-power/51155 "2020-12-03T00:02:23Z")\
**Posts on this page:** 1\
**Showing post:** 49

<div class="post-metadata">

**Author:** ![ToucheSir](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/touchesir/32/14411_2.png) [@ToucheSir](https://discourse.julialang.org/u/ToucheSir)\
**Post date:** [December 4, 2020, 6:05pm UTC](https://discourse.julialang.org/t/ensure-julia-is-used-to-its-full-power/51155/49 "2020-12-04T18:05:43Z")

</div>

> [@akalinin](#):
>
> But could we do this in another way with the same performance? My answer is this is the NumPy arrays. It does not mean that we can write always NumPy-vectorized non-pythonic style. The NumPy is the core API, core interface that can link all part of codes together. Like TensorFlow based on concept of Tensors.
> 
> Yes, this is the little bit dirty. But it works  
> a) You can use NumPy arrays itself in vectorized style.  
> b) You can use old plain pythonic style loops over NumPy arrays, you only need add “@jit” Numba annotation to compile it with LLVM to the native code. Yes, in modern Python you can just add @jit to a function to get the LLVM code with native performance.  
> c) You can use JAX to trace all NumPy operation to convert it to differentiable programming style.  
> d) You can send NumPy array to any language (C, C++, Fortran) without any overhead.
> 
> This solution is not as beautiful as in julia types system with multiple dispatch. This is some kind of Unix engineering way to make things working.

This is _exactly_ the purpose Julia’s built-in array type accomplishes. Instead of making their own somewhat numpy-compatible APIs (that’s what JAX is. It is _not_ a drop-in replacement), Julia libraries can rely on `Array`/`AbstractArray` with zero additional overhead.

Going a bit more abstract, multiple dispatch is a _means to an end_ and not an end in itself. Yes, part of why Julia can generate such fast code is that multiple dispatch allows for specialization on certain types. However, that does not mean that a) Julia can’t generate fast code without multiple dispatch, and b) compile-time latency will be eliminated if multiple dispatch is removed. I find it helpful to think about things this way:

> [@akalinin](#):
>
> b) You can use old plain pythonic style loops over NumPy arrays, you only need add “@jit” Numba annotation to compile it with LLVM to the native code. Yes, in modern Python you can just add @jit to a function to get the LLVM code with native performance.

Imagine every Python function you wrote was automatically run through Numba. As you can imagine, that would be painfully slow even though there is no multiple dispatch going on. Why do I bring this up? That is (conceptually) Julia’s compilation model. In this light, you can see how Julia is actually much “faster” than one would expect from naively JITing all code all the time.

Now, what if you don’t need this aggressive auto-compilation (e.g. in your cron job)? Julia exposes mechanisms for saying “I don’t care about optimization, just run the code”. See [this post](https://discourse.julialang.org/t/can-julia-really-be-used-as-a-scripting-language-performance/40384/66) for a quick overview.

> [@akalinin](#):
>
> From other side now Python almost solved all problems with the performance.

My intent here is not to write a “you’re holding it wrong” post WRT pre-runtime latency in Julia. I use Python almost exclusively for my own work because the current ML stack doesn’t offer enough ROI to offset its tradeoffs for my particular use-cases.

That said, I think it is good to clear up misconceptions around how Julia works and why the statement above is **categorically false** outside of the narrow domains that some of us work in. I’ll just close by saying that you may find Julia’s approach to be far closer to the Unix Philosophy than the “numpy-shaped island/silo per library” model in Python land 🙂

---

_[View the full topic](https://discourse.julialang.org/t/ensure-julia-is-used-to-its-full-power/51155)._