Comment by logimame | Hacker News Reader

Comment by logimame | Hacker News Reader

Parent Full thread

Yeah, it's still dissapointing how much system resources it takes to get a plot running (even with all the improvements in 1.6, benchmark taken from https://www.oxinabox.net/2021/02/13/Julia-1.6-what-has-chang...).

    julia> @time (using Plots; display(plot(1:0.1:10, sin.(1:0.1:10))))
      9.694037 seconds (18.29 M allocations: 1.164 GiB, 4.17% gc time, 0.40% compilation time)

To be honest, this isn't really something the devs should be proud about. 10 seconds, 18.29 M allocations and 1.164 GiB of memory just to render a simple static image is just unacceptable. In order for Julia to be a good-enough language for general scientific usage the current slow LLVM-based JIT compiler sadly isn't enough. I really want Julia to succeed, but this one problem is triumphing over every good language feature.

In an ideal world Julia would have two backends:

- A fast, hand-made JIT backend (something like LuaJIT) which is mostly interpreted and only JIT-compiled in frequently run code paths.

- The current slow, almost-AOT-like LLVM backend which is only used for precompilation of packages

It's just like Debug/Release bulids in C++, except that the Debug builds are lightning fast to compile (but slower at runtime) and Release builds are slower to compile (but hyper-optimized for runtime speed). I guess there's going to be an immense engineering effort if something like this happens, given that Julia today is immensely coupled with the LLVM compiler/runtime. But that's just my pipe dream.

Agreed, that would be ideal. But it's also a little unrealistic in the short term - most languages don't have an interpreted and a compiled mode. I think there just isn't the dev manpower.

It's more useful to think of Julia's latency as a fundamental constraint of the compilation model. People don't complain that Python can't deliver static binaries, or that C++ is unsuitable for scripting. Julia's compiler can do both (although the "static binaries" haven't materialized, because noone seriously works on it), but the tradeoff is that you suffer from latency. That's fundamental. Future versions of Julia may cut the compilation time down further, but it will never be instant or even close to instant.

So, like other languages, it means you have to look at the strengths and weaknesses of the language for your use case. For myself, I can't imagine a situation where I want to plot something right now and not in 15 seconds. Whenever I plot something, it's always after minutes or (usually) hours of data analysis. Most of my Julia use is either long, interactive sessions where ten seconds of startup doesn't matter much, or long-running pipelines where it doesn't, either.

Little-known fact: there is a Julia interpreter, if anyone really wants to go that way: https://github.com/JuliaDebug/JuliaInterpreter.jl

> I can't imagine a situation

If you have N scripts that produce N plots for a paper, you can't just drop them in a makefile or you will pay the 15 second penalty over and over and over every time you build. You can't reset the interactive session as a matter of habit to aggressively control state build-up. Even iterating on a dashboard becomes painful with a long startup time. You have to treat your Julia session like a child, not like cattle. That's limiting and not everyone wants to it, especially now that they are used to treating python sessions like cattle and reaping the benefits.

Here we go again. Those allocations and run time can be avoided entirely using sysimages. Latest vscode extension gives a convenient build task for this.

It seems like every time julia is mentioned, someone has to clarify this.

The problem I seem with sysimages, is that the whole process is incredibly unergonomic for exploratory coding, which Julia always claims it is a primary use-case for. When you want to just glue some packages and quickly test out some results, the last thing you want to do is to think about what kinds of functions from libraries you are going to use beforehand, carefully write it in a precompilation file, and wait for the compiler to precompile and cache those code paths! And once those dependencies change even a bit you need to wait for precompilation again, which happens a lot when you're prototyping things fast or upgrading versions (for example, this X numerical computation library doesn't have a particular feature I want to use, so I want to switch to another library Y, but then you need to wait for everything to be precompiled again) The reality is that most people just want to fire up a virtualenv and do the occasional "pip install <my libraries>" and don't want to get involved in any of this stuff. (As someone who uses C++ I have a lot more patience than other people, but you shouldn't really expect much from others)

I think Julia needs to throw away some of the unnecessary obsession for just-ahead-of-time (JAOT) compilation. Compiling everything beforehand to LLVM machine code seems good for raw runtime speed, but it doesn't matter when it takes so much setup time to even just glue some simple libraries. Julia should seriously consider running most of the less-computationally intensive codepaths in a custom-made interpreter without LLVM, while precompiling the numerically intensive parts of library code in raw machine code with the current LLVM backend. Maybe there should be a flag you can use to mark certain functions to be unconditionally compiled AOT-style, and leave the rest to the interpreter. Interpreters can be made surprisingly fast with some effort - stuff like the interpreter in LuaJIT (https://luajit.org/) and HashLink (https://hashlink.haxe.org/) is what comes into my mind.

To me separating compiler and interpreter looks like a new two languages problem (maintaining consistency seems difficult)

It would be the same code running on two different backends, so there would not be a two-language problem. Just like how GCC and Clang don't give C a two-language problem.

2 language problem for the Julia developer. Also these two languages might drift apart over time

They just explained to you that this idea has nothing to do with two different languages and that there are other examples of having multiple compilers for one language.

It's not a problem if the language spec is well defined. Scheme distributions often do this.

AFAIK Julia doesn’t even have a well-defined syntax (there’s no specification such as a context-free grammar, only the implementation of the parser).

Regarding your first paragraph, I must ask, have you done significant coding in Julia? Because an outdated sysimage is not really that big of a problem in practice. I have a sysimage which includes common big packages for plotting, numerical computing and some prettifying stuff I like like OhMyREPL. Then during dev time I add and remove packages, the compile time for those is significant enough to be noticed but not significant enough to be a problem. Because of the great composability of Julia, I'm guessing internally its using those big libraries and thus find most stuff precompiled for them. But I can't be sure about that.

Anyways, this is just my experience and my job involves a lot of waiting and stuff anyways so a couple seconds here and there doesn't bother me.

If it worked by default out of the box, nobody would have to "clarify" that you can decrease Julia's computational slowness by increasing the human time and effort spent on cache management

:/

Reply on news.ycombinator.com