# Computational Speed

**URL:** https://discourse.julialang.org/t/computational-speed/22572
**Category:** General Usage
**Tags:** question
**Created:** [March 31, 2019, 10:28pm UTC](https://discourse.julialang.org/t/computational-speed/22572 "2019-03-31T22:28:37Z")
**Posts on this page:** 1
**Page:** 2

<div class="post-metadata">

### Author: ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)
#### Post date: [April 1, 2019, 12:23pm UTC](https://discourse.julialang.org/t/computational-speed/22572/23 "2019-04-01T12:23:29Z")

</div>

> [@foobar\_lv2](#):
>
> Afaik the main problem is the possibility of running afoul of the GPL when distributing binaries that form a derived work (MRAN, Julia) of GPL code (R, GMP) and unfree code (MKL). I don’t exactly see how a deal between MS and intel helps with that.

Another problem is that if Julia links to MKL with the 64-bit BLAS API then any packages that link to libraries using the ordinary MKL API (32-bit BLAS) will crash. For example, any packages calling Python numpy routines, such as PyPlot, will crash with an MKL numpy (see e.g. [Segfault with Julia MKL build (library conflict) · Issue #443 · JuliaPy/PyCall.jl · GitHub](https://github.com/JuliaPy/PyCall.jl/issues/443)).

Of course, this is related to MKL being non free/open-source — otherwise, we could recompile MKL with renamed symbols to avoid library conflicts, like we do with OpenBLAS. (We could try to do it at the binary level with `objcopy` ala [RFC: Patch openblas to add 64\_ suffix when using 64 bit ints by tkelman · Pull Request #8734 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/pull/8734) … I’m not sure if that would be permissible according to the MKL license?)

[Previous page](https://discourse.julialang.org/t/computational-speed/22572.md?page=1)