Hacker News Reader

Comment by enriquto | Hacker News Reader

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).

View on HN

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). 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.

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.

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.

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

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.

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)

> when things like C++ succeed by not having huge blindsides and pitfalls

what??

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.

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.

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

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

> 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.

I think the focus is on interactive use, there are surely better options for scripts and one liners

Well, we have different ideas of calculators then.

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

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.

> I expect to be able to use it to compute intermediary results in a shell loop

You have a very peculiar use case that most other users don't! ...either you write a shell script, or a Julia script. It's preposterous to want everything to "start instantly", you'll only get stuck with the simplest most primitive tools this way. We'd all be writing C, Bash and PHP by this reasoning.

> If I need a simple calculator, I expect to be able to use it to compute intermediary results in a shell loop.

No offense but that must be one of the dumbest ideas I have heard in a long time. The reason you write something in a shell script is because it is portable on all Unix systems. If you add a dependency to a particular programming language like Julia, then that portability is out the windows. You require installing users to install Julia first.

If you require users to install Julia, you might as well ditch the shell script all together. All shell languages suck anyway for anything non-trivial.

I have rewritten plenty of shell scripts to Julia. It is much faster to write. The code is easier to read and understand and it executes way faster than any shell script.

Running a complicated shell script that calls out to Julia 1000 times makes absolutely NO SENSE! It is a completely contrived example with no practical application.

Besides when people say "calculator," I think most reasonable people assume an interactive system for doing calculations, not a glorified math library. Julia offers a great interactive environment for doing calculations.

> No offense but that must be one of the dumbest ideas I have heard in a long time.

Thanks. This is not the first time I've been told that.

> The reason you write something in a shell script is because it is portable on all Unix systems.

This is definitely not my case. I write plenty of shell code at work, but rarely distribute it. It is just for arranging data around, preparing one-off experiments, and so on.

> Running a complicated shell script that calls out to Julia 1000 times makes absolutely NO SENSE!

I agree that this may be a rare use case, but it is legitimate nonetheless. Moreover, the best tools are those that can be used successfully in ways that the creator of the tool would find abhorrent.

> It is a completely contrived example with no practical application.

This was a concrete example actually. I had a shell script that cropped, denoised and registered a collection of a few thousand photos scattered in a directory tree. It was a four-line pipeline that called a few command line tools from imagemagick and gmic to do the image processing work. At one point, I realized that I had to apply an homography to the images (given by a 3x3 matrix that was stored as 9 numbers in a text file) to map them to a different coordinate system. This involved a 3x3 matrix multiplication for each image. I did this multiplication in julia, my favorite calculator. The running time of the whole thing went from 10 to 20 minutes. Doing the "correct" thing and rewriting everything in julia would be extremely painful.

> Besides when people say "calculator," I think most reasonable people assume an interactive system for doing calculations

When you say "CLI Calculator", you can also think about a calculator that you can call from your shell command line. This is the case for example for the classical calculators bc(1) and dc(1), which are non-interactive, and purposefully intended to be called inside loops in a shell script.

> Doing the "correct" thing and rewriting everything in julia would be extremely painful.

Not necessarily: https://docs.julialang.org/en/v1/manual/running-external-pro...

That's great! I didn't know about that

This is simply not true. I have a 3 year old mac, and this is doing simple arithmetic (including starting and exiting Julia). 0.14 seconds user time.

  $ time ~/Desktop/Julia_Releases/Julia-1.4.app/Contents/Resources/julia/bin/julia -E "1+1"                    
  2
  ~/Desktop/Julia_Releases/Julia-1.4.app/Contents/Resources/julia/bin/julia -E   0.14s user 0.08s system 65% cpu 0.342 total

In about 0.5 seconds, I can actually do something non-trivial that actually needs non-trivial compilation - like summing the sin of a million random numbers

  $ time ~/Desktop/Julia_Releases/Julia-1.4.app/Contents/Resources/julia/bin/julia -E "sum(sin.(rand(1000000)))" 
  460165.3756259715
  ~/Desktop/Julia_Releases/Julia-1.4.app/Contents/Resources/julia/bin/julia -E   0.59s user 0.13s system 93% cpu 0.769 total

By half a second I obviously didn't mean 0.5 seconds but rather a very short duration that I didn't bother to measure.

Edit: Now I bothered to measure. You were saying?

      ~ time julia -E "1+1"
    2
    julia -E "1+1"  0,59s user 0,14s system 153% cpu 0,476 total

      ~ time julia -E "sum(sin.(rand(1000000)))" 
    459807.21199623536
    julia -E "sum(sin.(rand(1000000)))"  1,01s user 0,17s system 125% cpu 0,948 total

Which version of Julia are you using?

My main point was that while half a second (~0.5s) is perceptible startup time, ~0.1s is not. Is it a much older system than mine? I have a 2.3GHz Core i5 from about 2017.

I'm using 1.4 on an Intel i5 4460, so about 3 years older but not a laptop cpu.

I don't even think 0.5 seconds are that noticeable...

“3 years older but not a laptop cpu” might mean “spinning disk”, rather than SSD, too.

Nope, everything is on a new SSD.

I load a few packages in my startup. `--startup=no` makes the difference between about 0.12s and 0.5s on the 1+1 example for me.

This doesn't really bother me, but maybe I should try PackageCompiler or adding `using OhMyREPL, Revise, Cthulhu, BenchmarkTools` to a userimg.jl for when I build from source.

The only think I'm loading at startup is OhMyREPL.

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.

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)

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

Reply on news.ycombinator.com