4 ms·

I switched to Julia from Python due to facing the classic '2-language problem' of scientists. We wanted an easy to use API and good speed. The main bottleneck

I switched to Julia from Python due to facing the classic '2-language problem' of scientists. We wanted an easy to use API and good speed. The main bottleneck was computing the Mittag-Leffler function. First we tried in Python, then we get a ~10x improvement by outsourcing that bit to Fortran. The Julia implementation of the Mittag-Leffler function is comparable to Fortran but writing the entire software package in Julia led to ~5x speedup due to avoiding language interop issues and taking advantage of other Julia-specific benefits.

xenonite 7y ago
So, you obtained a 5x speedup of the whole package compared to the Python version with some Fortran extensions?
- montalbano 7y ago
  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).
Rochus 7y ago
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 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.
- improbable22 7y ago
  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/ https://docs.julialang.org/en/v1/manual/performance-tips/
  - montalbano 7y ago
    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.
    - Rochus 7y ago
      If you can measure you don't have to imagine.
      - deleted 7y ago
        [deleted]
- eigenspace 7y ago
  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.
  - Rochus 7y ago
    Well, weird benchmarks are probably all those where your favorite language doesn't look good ;-)
    - eigenspace 7y ago
      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).

xenonite 7y ago

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

montalbano 7y ago
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).

Rochus 7y ago

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 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.

improbable22 7y ago
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/ https://docs.julialang.org/en/v1/manual/performance-tips/
- montalbano 7y ago
  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.
  - Rochus 7y ago
    If you can measure you don't have to imagine.
    - deleted 7y ago
      [deleted]
eigenspace 7y ago
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.
- Rochus 7y ago
  Well, weird benchmarks are probably all those where your favorite language doesn't look good ;-)
  - eigenspace 7y ago
    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).