4 ms·

The article was written in 2016 (from the URL). Have some of the authors criticisms been addressed in the latest release? I know that startup time for Julia is

The article was written in 2016 (from the URL). Have some of the authors criticisms been addressed in the latest release? I know that startup time for Julia is now much faster (and also faster than my IPython profile from anaconda).

llamaz 7y ago
yes, according tothe comment from rvz
sjkelly 7y ago
JIT overhead/startup time is still comparably large. There is https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl that helps reduce this overhead in user libraries. The base library precompiles quite a few methods already, so the performance deficit relative to C and Python on Julia 1.2 is half that quoted in the article, and unchanged by statically compiling. Personally, I do a lot of computational geometry in Julia and I really don't care so much about these kinds of small overheads since actual computation time is the dominant factor. I imagine if Julia was designed for scripting in Unix environments this would be a bigger deal, but I think most people in the Julia community care more about how to manage several gigabytes of data in RAM/cache and run some analysis quickly, e.g. composable multithreading in 1.3.
leiroigh 7y ago
Some have been partially addressed. But the main point is that the critique is misguided in its generality. If the author cares about running many small scripts that each take a handful of milliseconds, then julia is just not the right tool for his job. No need to write overly general angry posts like "julia is slow"; instead write "julia has sluggish startup time". This is to some extent unavoidable, since julia has a quite heavy runtime (need to load llvm). For some workloads, bash / python / perl are more appropriate tools. To give you an example, `$ time julia -e "print(5)"` gives me about 230 ms, compared to python 35 ms. The language is designed for longer running programs that compute heavy stuff. And it performs very well at its intended use.

llamaz 7y ago

yes, according tothe comment from rvz

sjkelly 7y ago

JIT overhead/startup time is still comparably large. There is https://github.com/JuliaLang/PackageCompiler.jl https://github.com/JuliaLang/PackageCompiler.jl that helps reduce this overhead in user libraries. The base library precompiles quite a few methods already, so the performance deficit relative to C and Python on Julia 1.2 is half that quoted in the article, and unchanged by statically compiling. Personally, I do a lot of computational geometry in Julia and I really don't care so much about these kinds of small overheads since actual computation time is the dominant factor. I imagine if Julia was designed for scripting in Unix environments this would be a bigger deal, but I think most people in the Julia community care more about how to manage several gigabytes of data in RAM/cache and run some analysis quickly, e.g. composable multithreading in 1.3.

leiroigh 7y ago

Some have been partially addressed. But the main point is that the critique is misguided in its generality. If the author cares about running many small scripts that each take a handful of milliseconds, then julia is just not the right tool for his job. No need to write overly general angry posts like "julia is slow"; instead write "julia has sluggish startup time". This is to some extent unavoidable, since julia has a quite heavy runtime (need to load llvm). For some workloads, bash / python / perl are more appropriate tools. To give you an example, `$ time julia -e "print(5)"` gives me about 230 ms, compared to python 35 ms. The language is designed for longer running programs that compute heavy stuff. And it performs very well at its intended use.