5 ms·

I love the julia language. I would love to use julia as a command line calculator. Unfortunately, starting the interpreter is excruciatingly slow, an order of

I love the julia language. I would love to use julia as a command line calculator. Unfortunately, starting the interpreter is excruciatingly slow, an order of magnitude slower than octave or python (and several orders of magnitude slower than bc or dc).

Sukera 6y ago
One way to alleviate the slowish startup is to use PackageCompiler.jl (discussed at the end of the article https://krasjet.com/rnd.wlk/julia/#packagecompiler.jl https://krasjet.com/rnd.wlk/julia/#packagecompiler.jl). I like that there's more than just the standard calculator operations available at the REPL, but I can see why you wouldn't use it if you don't need it and bc satisfies your needs.
- BubRoss 6y ago
  I remember years ago when caching was about to be integrated in the next version and be here in a few weeks. Now it has been half a decade of people complaining about how slow it is for his to keep recompiling the same thing over and over.
  - Sukera 6y ago
    I've been using julia for about three years now and from my interactions with devs and the issues on github, caching more code has only been considered in the past year because before then, the priorities were in getting the language stable, to 1.0, and on other lower-hanging performance fruit. "Just cache more" turns out to be a harder problem than it seems at first sight, if by the very nature of the language loading a package can invalidate your caches. It has to be done with much caution, in order to reduce those invalidations as much as possible, which is why it takes time to figure it out.
    - cbkeller 6y ago
      Yeah, Julia has had some form of precompilation/caching for ages now, but sorting out all invalidations appears to be highly nontrivial [1] and devs have had more fundamental priorities pre-1.0. There have been some substantial improvements to latency in the meanwhile nonetheless, and PackageCompiler.jl is a viable option as well. [1] https://github.com/JuliaLang/www.julialang.org/pull/794 https://github.com/JuliaLang/www.julialang.org/pull/794
      - BubRoss 6y ago
        Just saying caching is difficult doesn't gel with my experience of what seems like low hanging fruit. I realize a lot of Julia ends up being templates, but when just one line of importing the same plotting package always takes 30 seconds or so, I get suspicious of the idea that all the usability warts are super difficult to solve. This has always been a huge complaint for Julia and it seems like one of those things that happens to new languages. People are excited, there are a few big rough edges that drive people away, they get ignored or underprioritized for WAY too long, and a giant window of opportunity is missed. I think of D with weeding out garbage collection, go with generics, D with tools and infrastructure, Zig with its refusal to parse carriage returns or tabs, Rust with compilation times, everyone with a lack of an easy road to a GUI, Jai not being released at all... I think instead of getting lots of areas to a decent stage, languages end up trying to be the best in a single area and placate their hardcore users, when things like C++ succeed by not having huge blindsides and pitfalls, even if it ends up a little rougher in many areas.
        cbkeller 6y ago
        Sure, just saying it's not that they haven't tried. If you have some specific ideas for low-hanging fruit that you think the Julia devs have missed though, I'm sure they'd welcome a PR! edit: also, time-to-first-plot is a lot less than 30 seconds for me these days, even without PackageCompiler. (time-to-second-plot is, as usual, instantaneous)
        dnautics 6y ago
        > when things like C++ succeed by not having huge blindsides and pitfalls what??
dunefox 6y ago
Simply loading the REPL takes half a second for me. I use it all the time as a simple calculator.
- enriquto 6y ago
  > Simply loading the REPL takes half a second for me. I juse it all the time as a simple calculator. Half a second is precisely what is meant by "excruciatingly slow". If I need a simple calculator, I expect to be able to use it to compute intermediary results in a shell loop. If my loop has one thousand iterations, you are spending about 10 minutes just initializing the interpreter. This is absurd. Of course, you can rewrite your whole loop upside down, so that the interpreter is called outside the loop. But this kind of defeats the goal of considering julia to be a general-purpose calculator, orthogonal with its usage patterns.
  - 4gotunameagain 6y ago
    I think the focus is on interactive use, there are surely better options for scripts and one liners
  - dunefox 6y ago
    Well, we have different ideas of calculators then.
  - grandinj 6y ago
    that sounds like a case where it would be best to pipe stuff into julia and read the output. or hack up a daemon-process thing where you can start it up outside the loop, then call it inside the loop
  - Sukera 6y ago
    The strength of using the julia REPL as a "calculator" is not in doing somewhat trivial calculations like dividing two numbers or quickly multiplying two things, and that's fine. That's not a goal of the REPL and julia is indeed overkill for those kinds of things. However, if you're mathematically inclined and sketch out a few matmuls like in the OP article, julia does have the benefit of making those kinds of interactions more bearable from a syntactic point of view. That's where it shines. And like I've posted above, if you use certain packages frequently and restart the REPL frequently, why not use PackageCompiler to compile your hot paths into your binary, like described in the article (admittedly at the end)? That way, even the first call in a new session will be fast because it has already been compiled. On top of that, the core devs are very much aware that this is a problem and it's actively being worked on.
eismcc 6y ago
Maybe a daemon model would be helpful here. REPL client could just boot instantly and forward operations to an already running Julia daemon
eigenspace 6y ago
Besides the other suggestions, you can do things like start julia using the --compile=min or -O0 command line flags to reduce / eliminate compilation overhead and make it startup quicker. The beta version of version 1.5.0 starts up in 0.25 seconds with --compile=min and I believe it's the same on 1.4.0
leephillips 6y ago
I suspect that the author starts the julia REPL up in the morning and leaves is running all day, so startup time would not be important.
- junke 6y ago
  I have a Lisp process that has been running for weeks now (window manager + devel. stuff), and any time I need to compute something I can go the REPL. I suppose Snail could be used in a same way (https://github.com/gcv/julia-snail https://github.com/gcv/julia-snail)
socialdemocrat 6y ago
How long does it take to start on your computer? If I have run it before. It takes less than 0.25 seconds. I use a several years old Mac. On none of my computers do I experience startup times which has any practical relevance to being productive. The only real problem I have experienced in Julia is using plotting libraries and those you can include in your Julia image with PackageCompiler.
- pavon 6y ago
  For me on Debian stable running version 1.0 takes about a second or two to start the repl the first time, less than a second on subsequent runs. On Windows 10 running version 1.3, it takes 10s of seconds every time. Also often times on windows it will load but never display anything until I press a key, so that timing is with me spamming the enter key.

Sukera 6y ago

One way to alleviate the slowish startup is to use PackageCompiler.jl (discussed at the end of the article https://krasjet.com/rnd.wlk/julia/#packagecompiler.jl https://krasjet.com/rnd.wlk/julia/#packagecompiler.jl). I like that there's more than just the standard calculator operations available at the REPL, but I can see why you wouldn't use it if you don't need it and bc satisfies your needs.

BubRoss 6y ago
I remember years ago when caching was about to be integrated in the next version and be here in a few weeks. Now it has been half a decade of people complaining about how slow it is for his to keep recompiling the same thing over and over.
- Sukera 6y ago
  I've been using julia for about three years now and from my interactions with devs and the issues on github, caching more code has only been considered in the past year because before then, the priorities were in getting the language stable, to 1.0, and on other lower-hanging performance fruit. "Just cache more" turns out to be a harder problem than it seems at first sight, if by the very nature of the language loading a package can invalidate your caches. It has to be done with much caution, in order to reduce those invalidations as much as possible, which is why it takes time to figure it out.
  - cbkeller 6y ago
    Yeah, Julia has had some form of precompilation/caching for ages now, but sorting out all invalidations appears to be highly nontrivial [1] and devs have had more fundamental priorities pre-1.0. There have been some substantial improvements to latency in the meanwhile nonetheless, and PackageCompiler.jl is a viable option as well. [1] https://github.com/JuliaLang/www.julialang.org/pull/794 https://github.com/JuliaLang/www.julialang.org/pull/794
    - BubRoss 6y ago
      Just saying caching is difficult doesn't gel with my experience of what seems like low hanging fruit. I realize a lot of Julia ends up being templates, but when just one line of importing the same plotting package always takes 30 seconds or so, I get suspicious of the idea that all the usability warts are super difficult to solve. This has always been a huge complaint for Julia and it seems like one of those things that happens to new languages. People are excited, there are a few big rough edges that drive people away, they get ignored or underprioritized for WAY too long, and a giant window of opportunity is missed. I think of D with weeding out garbage collection, go with generics, D with tools and infrastructure, Zig with its refusal to parse carriage returns or tabs, Rust with compilation times, everyone with a lack of an easy road to a GUI, Jai not being released at all... I think instead of getting lots of areas to a decent stage, languages end up trying to be the best in a single area and placate their hardcore users, when things like C++ succeed by not having huge blindsides and pitfalls, even if it ends up a little rougher in many areas.
      - cbkeller 6y ago
        Sure, just saying it's not that they haven't tried. If you have some specific ideas for low-hanging fruit that you think the Julia devs have missed though, I'm sure they'd welcome a PR! edit: also, time-to-first-plot is a lot less than 30 seconds for me these days, even without PackageCompiler. (time-to-second-plot is, as usual, instantaneous)
      - dnautics 6y ago
        > when things like C++ succeed by not having huge blindsides and pitfalls what??

dunefox 6y ago

Simply loading the REPL takes half a second for me. I use it all the time as a simple calculator.

enriquto 6y ago
> Simply loading the REPL takes half a second for me. I juse it all the time as a simple calculator. Half a second is precisely what is meant by "excruciatingly slow". If I need a simple calculator, I expect to be able to use it to compute intermediary results in a shell loop. If my loop has one thousand iterations, you are spending about 10 minutes just initializing the interpreter. This is absurd. Of course, you can rewrite your whole loop upside down, so that the interpreter is called outside the loop. But this kind of defeats the goal of considering julia to be a general-purpose calculator, orthogonal with its usage patterns.
- 4gotunameagain 6y ago
  I think the focus is on interactive use, there are surely better options for scripts and one liners
- dunefox 6y ago
  Well, we have different ideas of calculators then.
- grandinj 6y ago
  that sounds like a case where it would be best to pipe stuff into julia and read the output. or hack up a daemon-process thing where you can start it up outside the loop, then call it inside the loop
- Sukera 6y ago
  The strength of using the julia REPL as a "calculator" is not in doing somewhat trivial calculations like dividing two numbers or quickly multiplying two things, and that's fine. That's not a goal of the REPL and julia is indeed overkill for those kinds of things. However, if you're mathematically inclined and sketch out a few matmuls like in the OP article, julia does have the benefit of making those kinds of interactions more bearable from a syntactic point of view. That's where it shines. And like I've posted above, if you use certain packages frequently and restart the REPL frequently, why not use PackageCompiler to compile your hot paths into your binary, like described in the article (admittedly at the end)? That way, even the first call in a new session will be fast because it has already been compiled. On top of that, the core devs are very much aware that this is a problem and it's actively being worked on.

eismcc 6y ago

Maybe a daemon model would be helpful here. REPL client could just boot instantly and forward operations to an already running Julia daemon

eigenspace 6y ago

Besides the other suggestions, you can do things like start julia using the --compile=min or -O0 command line flags to reduce / eliminate compilation overhead and make it startup quicker. The beta version of version 1.5.0 starts up in 0.25 seconds with --compile=min and I believe it's the same on 1.4.0

leephillips 6y ago

I suspect that the author starts the julia REPL up in the morning and leaves is running all day, so startup time would not be important.

junke 6y ago
I have a Lisp process that has been running for weeks now (window manager + devel. stuff), and any time I need to compute something I can go the REPL. I suppose Snail could be used in a same way (https://github.com/gcv/julia-snail https://github.com/gcv/julia-snail)

socialdemocrat 6y ago

How long does it take to start on your computer? If I have run it before. It takes less than 0.25 seconds. I use a several years old Mac. On none of my computers do I experience startup times which has any practical relevance to being productive. The only real problem I have experienced in Julia is using plotting libraries and those you can include in your Julia image with PackageCompiler.

pavon 6y ago
For me on Debian stable running version 1.0 takes about a second or two to start the repl the first time, less than a second on subsequent runs. On Windows 10 running version 1.3, it takes 10s of seconds every time. Also often times on windows it will load but never display anything until I press a key, so that timing is with me spamming the enter key.