back
2 comments
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).