5 ms·

> JITs can accelerate slow languages, at a stiff RAM penalty, but they still remain noticeably slower than faster languages. The Julia language would like a w

> JITs can accelerate slow languages, at a stiff RAM penalty, but they still remain noticeably slower than faster languages. The Julia language would like a word. It compiles to native machine code via LLVM, which is the same backend that a lot of statically typed languages use, and bar it's very first run, it can run blindingly fast: I've been using it instead of Python at work for Data Science things and it's been great.

kibwen 8y ago
As I understand it, Julia's current implementation is not a JIT in any comparable sense to the JVM. Julia's JIT does not use any runtime information to optimize code; it's literally just statically compiling each function on-demand as they are encountered. You would get equivalent runtime performance by having a separate up-front compiler step, as C has. And actually, this sort of implies that Julia doesn't do inlining, the mother of all optimizations, which would mean that you'd be sacrificing quite a lot of runtime performance compared to an up-front compiled implementation. https://discourse.julialang.org/t/notes-on-the-julia-compiler-jit-vs-static/4275 https://discourse.julialang.org/t/notes-on-the-julia-compile...
- byt143 8y ago
  Actually Julia is aggressively inlined because it's easy to statically determine function calls at compile time...that's why the libraries are able to use such nice abstractions. It's already ahead of time compilable, just needs some work to emit smaller binaries and cover some corner cases
  - kibwen 8y ago
    Good to know, thanks.
- jashmatthews 8y ago
  > As I understand it, Julia's current implementation is not a JIT in any comparable sense Going straight to machine code via baseline compilation is a common JIT technique. Until a couple of years ago, V8 compiled everything.
  - kibwen 8y ago
    Baseline compilation is fine, that wasn't what I was referring to. I the context of this thread, the long-awaited promise of JIT is the ability to profile running code to dynamically determine the hot portions and re-optimize on the fly, and do this continually for the entire runtime of the program. This is what people mean by "things that are impossible for a static compiler to do" (though PGO is a decent approximation), and the basis of all discussions that begin with "actually, Java can be faster than C". This is not to say that Julia does not satisfy the definition of a JIT, only that using Julia as an example of this principle appears to be mistaken. Julia is not fast because it dynamically re-optimizes, it's fast because it uses a mature C compiler backend.
- ihnorton 8y ago
  Julia does not have a tracing JIT right now, but does use runtime information in order to JIT specializations based on (often inferred) method argument types.
jerf 8y ago
For your point to be a disagreement, you'd first have to agree that Julia is a "slow language", that is sped up by a JIT. Would you agree with that? Or is it an example of a sort of language that I referenced, one that was designed to perform well from the beginning that may use some technology that looks like a JIT (though as others pointed out, not necessarily really the same)?

kibwen 8y ago

As I understand it, Julia's current implementation is not a JIT in any comparable sense to the JVM. Julia's JIT does not use any runtime information to optimize code; it's literally just statically compiling each function on-demand as they are encountered. You would get equivalent runtime performance by having a separate up-front compiler step, as C has. And actually, this sort of implies that Julia doesn't do inlining, the mother of all optimizations, which would mean that you'd be sacrificing quite a lot of runtime performance compared to an up-front compiled implementation. https://discourse.julialang.org/t/notes-on-the-julia-compiler-jit-vs-static/4275 https://discourse.julialang.org/t/notes-on-the-julia-compile...

byt143 8y ago
Actually Julia is aggressively inlined because it's easy to statically determine function calls at compile time...that's why the libraries are able to use such nice abstractions. It's already ahead of time compilable, just needs some work to emit smaller binaries and cover some corner cases
- kibwen 8y ago
  Good to know, thanks.
jashmatthews 8y ago
> As I understand it, Julia's current implementation is not a JIT in any comparable sense Going straight to machine code via baseline compilation is a common JIT technique. Until a couple of years ago, V8 compiled everything.
- kibwen 8y ago
  Baseline compilation is fine, that wasn't what I was referring to. I the context of this thread, the long-awaited promise of JIT is the ability to profile running code to dynamically determine the hot portions and re-optimize on the fly, and do this continually for the entire runtime of the program. This is what people mean by "things that are impossible for a static compiler to do" (though PGO is a decent approximation), and the basis of all discussions that begin with "actually, Java can be faster than C". This is not to say that Julia does not satisfy the definition of a JIT, only that using Julia as an example of this principle appears to be mistaken. Julia is not fast because it dynamically re-optimizes, it's fast because it uses a mature C compiler backend.
ihnorton 8y ago
Julia does not have a tracing JIT right now, but does use runtime information in order to JIT specializations based on (often inferred) method argument types.

jerf 8y ago

For your point to be a disagreement, you'd first have to agree that Julia is a "slow language", that is sped up by a JIT. Would you agree with that? Or is it an example of a sort of language that I referenced, one that was designed to perform well from the beginning that may use some technology that looks like a JIT (though as others pointed out, not necessarily really the same)?