So, you obtained a 5x speedup of the whole package compared to the Python version with some Fortran extensions?

Yes.

And for anyone wondering about the state of the Julia package ecosystem compared to Python, someone had already written the main two packages we needed in Julia (for Mittag-Leffler computation and Inverse Laplace computation). At that time there was no Mittag-Leffler implemented in Python or SciPy that I could find.

I could also add that we were computing integral equations with Mittag-Leffler function in the Kernels so in worst cases we needed O(n^2) calls to Mittag-Leffler function where n could be O(10^5).

If you need another speedup consider LuaJIT which is used at CERN for heavy number crunching and data analysis, see http://cds.cern.ch/record/2157242?ln=de. E.g. on slide 14: LuaJIT took 5.3 sec, C++/GCC 5.7 sec, PyPy 7.6 sec, Julia 35 sec and Python > 2 hours.

From the comments on that:

> No one should use global scope of Julia for calculations: [...] which is said that takes 35 seconds. > If you wrap it in a function and not had a type instability, You'd get 4.704 seconds...

Half-decently written Julia ought not to be much slower than C.

But it does also allow you to write quick and dirty scripts with no care for speed, which is also useful. It would be nice if people wouldn't benchmark the latter. The manual has a pretty helpful section for avoiding this: https://docs.julialang.org/en/v1/manual/performance-tips/

Indeed, I would imagine that well written Julia is on par with LuaJIT.

Even more importantly, from a cursory look online I cannot find any Lua implementation of either the Mittag-Leffler function or Inverse Laplace routines. And there is no reference to any wider ecosystem of scientific computing packages.

Sure I could call some C functions but then I'm back to facing a 2-language problem which I don't want.

Furthermore, it looks like there has been no new releases of LuaJIT since 2017. Development on it looks to have stopped.

If you can measure you don't have to imagine.

I watched the video, those benchmarks are just terrible. If one wants to use LuaJIT for a porject, sure go for it, but making up weird benchmarks like that which purposefully cripple competitor language performance is just embarrassing.

Well, weird benchmarks are probably all those where your favorite language doesn't look good ;-)

I would say in this case what's 'weird' about the benchmarks is that the optimization strategy taken across the languages is incredibly uneven. Indeed, simply wrapping the above julia code in a `let` block so it's not out in the global scope is sufficient to have it on par with C++ (assuming the same flags are used, e.g. fastmath).