3 ms·

Referring to start-up latency, the author asserts: > But the problem is fundamentally unsolvable, because it's built into Julia on a basic design level. Cita

Referring to start-up latency, the author asserts: > But the problem is fundamentally unsolvable, because it's built into Julia on a basic design level. Citation need. Today, the Julia compiler runs in JIT mode. But there is nothing preventing it from being ahead-of-time compiled (indeed, some work is going behind the scenes to make this happen). There is also an interpreter for Julia. I don't see latency or large memory footprints as being "fundamentally unsolvable".

lasagnaphil 5y ago
Yeah, though the solution for it basically seems to be "throw out all the previous code that was highly coupled with LLVM and actually write our own fast JIT compiler and interpreter from the ground up". It's possible, but probably takes an incredible amount of work and would maybe involve cloning a copy of Mike Pall (the creator of LuaJIT) to help on the project.
- snicker7 5y ago
  I don't think you need to rebuild the compiler. Here is a proposal how how this can be done using the work to compile Julia for GPU's: https://docs.google.com/document/d/1rLpZf-HK6b9uYPDT_piUza4LUhtIrLbUftGa_YaXGKQ/edit https://docs.google.com/document/d/1rLpZf-HK6b9uYPDT_piUza4L...
  - lasagnaphil 5y ago
    My response's more about the dynamic execution side of things (latency & memory bloat of Julia). Static compilation is a whole different topic, but I'm confident that it can be solved with existing LLVM infrastructure (because what's LLVM good at? static compilation!) The hardest part may be how to modify Julia's semantics to fit that paradigm (for instance, the need to introduce "header files" in the language, and all the gnarly details coming with it)
otabdeveloper4 5y ago
> I don't see latency or large memory footprints as being "fundamentally unsolvable". Dunno. Look at Python. Does "never in a million years, because switching to a better language would be easier" count as "fundamentally"?

lasagnaphil 5y ago

Yeah, though the solution for it basically seems to be "throw out all the previous code that was highly coupled with LLVM and actually write our own fast JIT compiler and interpreter from the ground up". It's possible, but probably takes an incredible amount of work and would maybe involve cloning a copy of Mike Pall (the creator of LuaJIT) to help on the project.

snicker7 5y ago
I don't think you need to rebuild the compiler. Here is a proposal how how this can be done using the work to compile Julia for GPU's: https://docs.google.com/document/d/1rLpZf-HK6b9uYPDT_piUza4LUhtIrLbUftGa_YaXGKQ/edit https://docs.google.com/document/d/1rLpZf-HK6b9uYPDT_piUza4L...
- lasagnaphil 5y ago
  My response's more about the dynamic execution side of things (latency & memory bloat of Julia). Static compilation is a whole different topic, but I'm confident that it can be solved with existing LLVM infrastructure (because what's LLVM good at? static compilation!) The hardest part may be how to modify Julia's semantics to fit that paradigm (for instance, the need to introduce "header files" in the language, and all the gnarly details coming with it)

otabdeveloper4 5y ago

> I don't see latency or large memory footprints as being "fundamentally unsolvable". Dunno. Look at Python. Does "never in a million years, because switching to a better language would be easier" count as "fundamentally"?