6 ms·

And slower (to start) than both of them. I tried julia to write some scripts that were previously in numpy, but the slow start threw me off. I hope they solve t

And slower (to start) than both of them. I tried julia to write some scripts that were previously in numpy, but the slow start threw me off. I hope they solve this because it's a great language.

davrosthedalek 5y ago
I thought Julia is a compiled language. Surprising that the startup is then so slow.
- najtdale 5y ago
  JIT compiled. Has a warmup time.
  - davrosthedalek 5y ago
    Ah, I see. That explains a lot. Could also be the reason why it beats gfortran in the test. A JIT knows more about the data the program sees/runtime behavior than a normal compiler. Still surprising. Or is gfortran just so much behind state of the art fortran compilers?
    - eigenspace 5y ago
      Not this test. Julia’s JIT compiler does not know about runtime values, it’s not a tracing JIT like the ones you may be used to. Instead, it’s ‘just ahead of time’, compiling a specialized executable for each new function signature the first time that signature gets hit. I.e. if I do f(x) = 2x + 1 The first time I call f(1) it’ll compile a function specialization for f( ::Int), and the first time you call f on that integer it’ll be slow and all the subsequent calls will be equally fast. Next if you do f(1.0 + 2im) it’ll compile a new specialization for f(::Complex{Float64}) which will be slow the first time while it compiles and then fast on all the subsequent runs. The genius of Julia’s design is that the JIT compiler is designed around the semantics of multiple dispatch, and the multiple dispatch semantics are designed around having a JIT
  - pletnes 5y ago
    It’s just-ahead-of-time compiled and no «interpreted mode» so it’s always slow to start, if I understand correctly. Really annoying, especially the first time you use it.
    - cbkeller 5y ago
      If you need to run small scripts and can't switch to a persistent-REPL-based workflow, you might consider starting Julia with the `--compile=min` option. If you know which packages you're going to need, you can also reduce startup times dramatically by building a sysimg with PackageCompiler.jl There is also technically an interpreter if you want to go that way [1], so in principle it might be possible to do the same trick javascript does, but someone would have to implement that. [1] https://github.com/JuliaDebug/JuliaInterpreter.jl https://github.com/JuliaDebug/JuliaInterpreter.jl
  - mwest217 5y ago
    That’s strictly accurate but kinda misleading. It doesn’t have multiple optimization passes it does just for hot code paths, it fully compiled per function. They call it Just Ahead Of Time compiled.
- acmj 5y ago
  Think about compiling a large C++ program and its dependencies every time you run the generated executable. This is sort of like what is Julia is doing.
eigenspace 5y ago
The startup times have improved a lot in version 1.6, the latest release, and are I Proving again in the next upcoming release candidate. Are you hitting the startup time very often? If so, you might want to try some things to keep one julia session open and sending code to it like a daemon instead of constantly closing and opening sessions. This package makes that workflow really easy: https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl
- superdimwit 5y ago
  I most often need to restart the REPL when redefining structs.
dosshell 5y ago
Same for me. Ported my calculations to Python from Julia. Even before Julia has started python was done. And Julia also did jit compilation in runtime. A function call could take seconds on first call.
- moelf 5y ago
  if it's that fast (<O(1s)) and your use-case is to call it many many times from ground-up, you sure should use Python or even bash since there's literally no performance to speak of. (i.e. nothing really changes the usability anyways)
  - kzrdude 5y ago
    Julia startup can easily be minutes with big libraries
    - moelf 5y ago
      `precompile` is a one-time thing. Actually loading them when running scripts is O(s) even for some of the biggest library (Plotting, Differential equations etc.)
jlamberts 5y ago
I have also recently been playing around with Julia coming from numpy/pandas. I found that 1.6.1 felt way smoother on startup and import than 1.5.x. Might be worth trying to upgrade if you haven't already. At the very least it's encouraging that it seems like they're making progress in that direction.
bobbylarrybobby 5y ago
Unfortunately Julia is a “repl-based language”. You are expected to open a repl and work in it for as long as possible so that your compilations all remain cached. Packages like Revise can help reevaluate code that changes so that you don’t have to leave the repl. I do wish that Julia would start up in an interpreted mode and compile in the background so that it would be fast enough when first opened and then attain maximum speed later on. (I think this is how JavaScript engines work?)
- eigenspace 5y ago
  You can have what you want here by using DaemonMode.jl https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl
  - snicker7 5y ago
    It would be nice if their was an "offline version" of this, e.g. automagically cache all compiled code to disk. Daemon mode isn't restart-friendly.
    - adgjlsfhk1 5y ago
      That's basically what PackageCompiler does. That said, StaticCompiler.jl is expected to improve the state of this in the future.
      - snicker7 5y ago
        Not quite. PackageCompiler isn't automagic. The sysimage doesn't get automatically updated in the REPL. You have to create one manually (and this requires tracing instead of static type inference which Julia can do). So the workflow isn't zero-friction. And StaticCompiler hasn't been updated in over a year. The problem with Julia tooling in general is that they feel 90% done. And tooling is, in my opinion, more important than the language itself.
        5y ago

And slower (to start) than both of them. I tried julia to write some scripts that were previously in numpy, but the slow start threw me off. I hope they solve this because it's a great language.

davrosthedalek 5y ago

I thought Julia is a compiled language. Surprising that the startup is then so slow.

najtdale 5y ago
JIT compiled. Has a warmup time.
- davrosthedalek 5y ago
  Ah, I see. That explains a lot. Could also be the reason why it beats gfortran in the test. A JIT knows more about the data the program sees/runtime behavior than a normal compiler. Still surprising. Or is gfortran just so much behind state of the art fortran compilers?
  - eigenspace 5y ago
    Not this test. Julia’s JIT compiler does not know about runtime values, it’s not a tracing JIT like the ones you may be used to. Instead, it’s ‘just ahead of time’, compiling a specialized executable for each new function signature the first time that signature gets hit. I.e. if I do f(x) = 2x + 1 The first time I call f(1) it’ll compile a function specialization for f( ::Int), and the first time you call f on that integer it’ll be slow and all the subsequent calls will be equally fast. Next if you do f(1.0 + 2im) it’ll compile a new specialization for f(::Complex{Float64}) which will be slow the first time while it compiles and then fast on all the subsequent runs. The genius of Julia’s design is that the JIT compiler is designed around the semantics of multiple dispatch, and the multiple dispatch semantics are designed around having a JIT
- pletnes 5y ago
  It’s just-ahead-of-time compiled and no «interpreted mode» so it’s always slow to start, if I understand correctly. Really annoying, especially the first time you use it.
  - cbkeller 5y ago
    If you need to run small scripts and can't switch to a persistent-REPL-based workflow, you might consider starting Julia with the `--compile=min` option. If you know which packages you're going to need, you can also reduce startup times dramatically by building a sysimg with PackageCompiler.jl There is also technically an interpreter if you want to go that way [1], so in principle it might be possible to do the same trick javascript does, but someone would have to implement that. [1] https://github.com/JuliaDebug/JuliaInterpreter.jl https://github.com/JuliaDebug/JuliaInterpreter.jl
- mwest217 5y ago
  That’s strictly accurate but kinda misleading. It doesn’t have multiple optimization passes it does just for hot code paths, it fully compiled per function. They call it Just Ahead Of Time compiled.
acmj 5y ago
Think about compiling a large C++ program and its dependencies every time you run the generated executable. This is sort of like what is Julia is doing.

eigenspace 5y ago

The startup times have improved a lot in version 1.6, the latest release, and are I Proving again in the next upcoming release candidate. Are you hitting the startup time very often? If so, you might want to try some things to keep one julia session open and sending code to it like a daemon instead of constantly closing and opening sessions. This package makes that workflow really easy: https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl

superdimwit 5y ago
I most often need to restart the REPL when redefining structs.

dosshell 5y ago

Same for me. Ported my calculations to Python from Julia. Even before Julia has started python was done. And Julia also did jit compilation in runtime. A function call could take seconds on first call.

moelf 5y ago
if it's that fast (<O(1s)) and your use-case is to call it many many times from ground-up, you sure should use Python or even bash since there's literally no performance to speak of. (i.e. nothing really changes the usability anyways)
- kzrdude 5y ago
  Julia startup can easily be minutes with big libraries
  - moelf 5y ago
    `precompile` is a one-time thing. Actually loading them when running scripts is O(s) even for some of the biggest library (Plotting, Differential equations etc.)

jlamberts 5y ago

I have also recently been playing around with Julia coming from numpy/pandas. I found that 1.6.1 felt way smoother on startup and import than 1.5.x. Might be worth trying to upgrade if you haven't already. At the very least it's encouraging that it seems like they're making progress in that direction.

bobbylarrybobby 5y ago

Unfortunately Julia is a “repl-based language”. You are expected to open a repl and work in it for as long as possible so that your compilations all remain cached. Packages like Revise can help reevaluate code that changes so that you don’t have to leave the repl. I do wish that Julia would start up in an interpreted mode and compile in the background so that it would be fast enough when first opened and then attain maximum speed later on. (I think this is how JavaScript engines work?)

eigenspace 5y ago
You can have what you want here by using DaemonMode.jl https://github.com/dmolina/DaemonMode.jl https://github.com/dmolina/DaemonMode.jl
- snicker7 5y ago
  It would be nice if their was an "offline version" of this, e.g. automagically cache all compiled code to disk. Daemon mode isn't restart-friendly.
  - adgjlsfhk1 5y ago
    That's basically what PackageCompiler does. That said, StaticCompiler.jl is expected to improve the state of this in the future.
    - snicker7 5y ago
      Not quite. PackageCompiler isn't automagic. The sysimage doesn't get automatically updated in the REPL. You have to create one manually (and this requires tracing instead of static type inference which Julia can do). So the workflow isn't zero-friction. And StaticCompiler hasn't been updated in over a year. The problem with Julia tooling in general is that they feel 90% done. And tooling is, in my opinion, more important than the language itself.
      - 5y ago