Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia 1.6 addresses latency issues

lwn.net

Post reply on HN
Print view View original

51–60 of 160 posts

Re: Julia 1.6 addresses latency issues

#51

Post by smabie »

So I used to be a big proponent of Julia, and in some ways, I still am. But I very recently tried to write a high performance production system in it, and was sorely disappointed. The tooling is just so buggy and it's clear that the community isn't really interested in using it for anything besides modeling/research in a Jupyter notebook.

Things that kind of suck about using Julia for production:

1. Never could get Revise to work, had to restart my REPL everytime I changed any code. Even though Julia 1.6 was a lot faster than 1.5, it still took too long.

2. Couldn't find a static type checker that actually worked (I tried JET and StaticLint). I feel like static typing is just so important for a production system, but of course the community isn't really interested because of the research focus.

3. Editor tooling. The LSP server absolutely sucks. I first tried using it with emacs (both lsp-mode and eglot mode), but it would crash constantly. I think switched to VSCode (much to my chagrin), and that worked marginally better though still very poorly. It was clear that the LSP server had no idea what was going on in my macro heavy code. It couldn't jump to definitions or usages much of the time. It could never correctly determine whether a variable was unused or misspelled either. Coupled with the lack of static type checking, this was extremely frustrating.

4. Never felt like the community could answer any of my questions. If you have some research or stats question, they were great, but anything else, forget about it.

Will all of that being said, I do still use Julia for research and I find it works really well. The language is very nicely designed.

All and all, I decided to ditch Julia and decided to go with Rust (after some consideration of OCaml, but unfortunately the multi-core story still isn't there yet) and am a lot happier.

Re: Julia 1.6 addresses latency issues

#52

Post by DNF2 »

enriquto wrote: post #12
adsharma wrote: post #6

For me the issue manifested as a 10 sec latency to format a Julia file using Format.jl Solved via flags to disable JIT and brought it down to a couple of secs. Native binary would be much nicer.

Two seconds to process a tiny text file enters well into the realm of "completely unusable" in my eyes. It wouldn't be so bad if the Julia developers acknowledged that this is a valid concern (that they are not dealing with it right now for whatever reasons) and that the ecosystem will not be considered complete until this fundamental problem is solved. But this is infuriatingly not the case. Instead, they tell you t…

I wonder where you got the impression that latency and precompilation performance are not valid concerns. This has been the _main_ focus area for the devs for a long time. It's pretty much all anyone has been talking about for over a year, and serious improvements have been made.

Here's a blog post that goes into some detail about the ongoing efforts to improve compiler latency: https://julialang.org/blog/2020/08/invalidations/

Re: Julia 1.6 addresses latency issues

#53

Post by hpcjoe »

up6w6 wrote: post #31
krastanov wrote: post #11

Earlier quoted context omitted.

Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? If you generate a "python binary", you need to package python with your binary. Same for perl/ruby. It just seems weird that people expect julia to be able to do that. It is cute that PackageCompiler.jl exists and it is cute that more AOT compilation work is being currently done, but it seems crazy to expect Julia to be good at…

> And by extension, it seems weird to me to complain that Julia is not a general purpose language because it can not generate binaries. What stops me from making the same statement about python, which is definitely general purpose? I agree that generating binaries don't make a language general purpose, I just tried to give an exemple of an ad hoc non scientific thing that is considered "important" to the community (i…

A non-scientific thing I've been doing for the last few months at the day job, with Julia.

1) querying a time series database of systems metrics at scale for (large) fleets. This is being done via a JSON API. Directly in Julia.

2) Creating data frames from these queries, and performing fleet wide analytics. Quickly. Millions to hundreds of millions of rows in the data frames, typically 4-20 columns. Directly in Julia, no appeal to a 2nd language.

3) leveraging the power of the language to post process these data sets before analysis, to remove an "optimization" that reduced data quality.

4) operate quickly on gigabytes of queried data, threading and sharding my requests, as the server can't handle large requests, but it can handle parallel ones. Poor design, but I can work around it ... trivially ... with Julia

5) creating jupyter lab notebooks for simple consumption of these more complex data sets by wider audiences, complete with plots, and other things.

No science done here ... well ... data science maybe ... and this is specifically in support of business analytics, process optimization, etc.

Julia is an excellent language for this, 10 out of 10, would recommend.

Re: Julia 1.6 addresses latency issues

#54

Post by pjmlp »

oblio wrote: post #49
pjmlp wrote: post #39

Earlier quoted context omitted.

Java and C# also have combined JIT and AOT since they exist, .NET moreso. Other examples are Lisp and Scheme variants, Eiffel, OCaml, Haskell, Prolog.

The main SDKs and programming paradigms for Java and C# both don't mesh well with AOT, though. Reflection, heavy reflection based frameworks. Not that many places use Java/C# AOT compilation, except for games/iOS apps. Almost every place I've seen using Java/C# was using JIT.

Android uses a mix of JIT/AOT, just as most Java embedded development.

As for not everything being supported, well that is no different from having C++ code with RTTI and exceptions disabled, or being forced into a specific linking model due to possible problems with a third party dependency.

Re: Julia 1.6 addresses latency issues

#55

Post by enriquto »

DNF2 wrote: post #52
enriquto wrote: post #12

Earlier quoted context omitted.

Two seconds to process a tiny text file enters well into the realm of "completely unusable" in my eyes. It wouldn't be so bad if the Julia developers acknowledged that this is a valid concern (that they are not dealing with it right now for whatever reasons) and that the ecosystem will not be considered complete until this fundamental problem is solved. But this is infuriatingly not the case. Instead, they tell you t…

I wonder where you got the impression that latency and precompilation performance are not valid concerns. This has been the _main_ focus area for the devs for a long time. It's pretty much all anyone has been talking about for over a year, and serious improvements have been made. Here's a blog post that goes into some detail about the ongoing efforts to improve compiler latency: https://julialang.org/blog/2020/08/inv…

> I wonder where you got the impression that latency and precompilation performance are not valid concerns.

Now that you ask it, I realise it's been mostly through a few HN interactions! Every time I raised the issue in Julia posts over the last few years, I have been consistently ridiculed by purported Julia defenders. For example, in this very thread you can find a case of that.

Re: Julia 1.6 addresses latency issues

#56

Post by galenlynch »

adgjlsfhk1 wrote: post #18
krastanov wrote: post #11

Earlier quoted context omitted.

Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? If you generate a "python binary", you need to package python with your binary. Same for perl/ruby. It just seems weird that people expect julia to be able to do that. It is cute that PackageCompiler.jl exists and it is cute that more AOT compilation work is being currently done, but it seems crazy to expect Julia to be good at…

The reason Julia should be able to do this is that it uses LLVM to generate machine code "just ahead of time". As such, (at least for type stable code), it should be possible to save the code we generate. The main place where static AOT matters for Julia isn't full applications, but libraries. Being able to generate static libraries would allow Julia to replace C++ and Fortran much more fully in places like python li…

This is true for many functions, but afaik the llvm code is only generated for a function paired with the types of the arguments that it was called with. Since Julia functions are for the most part 'generic' and work with a wide range of argument types, you would have to restrict the compiled binary or library to a specific set of argument types. Some functions also have type instability and can't be made into pure llvm.

Re: Julia 1.6 addresses latency issues

#57

Post by orbots »

krastanov wrote: post #11
up6w6 wrote: post #9

I use and love Julia but I really wanted to see the general purpose language that is claimed. On one hand, you see amazing scientific libs like DifferentialEquations.jl, on the other side, things like the PackageCompiler.jl mentioned just sucks at generating binaries for daily basis.

Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? If you generate a "python binary", you need to package python with your binary. Same for perl/ruby. It just seems weird that people expect julia to be able to do that. It is cute that PackageCompiler.jl exists and it is cute that more AOT compilation work is being currently done, but it seems crazy to expect Julia to be good at…

Julia claims to "solve the two language problem". i.e. prototype in python, rewrite in c++. The two language problem is not solved with Julia if you can't effectively generate binaries.

Re: Julia 1.6 addresses latency issues

#58

Post by [deleted] »

krastanov wrote: post #27
reikonomusha wrote: post #20

Earlier quoted context omitted.

Why is it such a ridiculous comparison? Gnuplot is still interpreting a language, loading plotting code, etc. If Julia folks wanted to, they could bundle pre-compiled plotting code that loads as fast as memory moves bytes. They don’t want to, of course, likely because it’s inelegant, but they could, and a general-purpose language doesn’t stop them from doing that.

You can already bundle pre-compiled plotting code in your Julia sys-image if you want. But Julia is not a plotting tool so it would be ridiculous to optimize it just for plotting. I want ODE solvers to have less latency, should I start expecting gnuplot to have built-in ODE solvers or the official installer of Julia to have the ODE libraries pre-compiled? Maybe this example would make it clearer: why does your argume…

[deleted]

Re: Julia 1.6 addresses latency issues

#59

Post by krastanov »

orbots wrote: post #57
krastanov wrote: post #11

Earlier quoted context omitted.

Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? If you generate a "python binary", you need to package python with your binary. Same for perl/ruby. It just seems weird that people expect julia to be able to do that. It is cute that PackageCompiler.jl exists and it is cute that more AOT compilation work is being currently done, but it seems crazy to expect Julia to be good at…

Julia claims to "solve the two language problem". i.e. prototype in python, rewrite in c++. The two language problem is not solved with Julia if you can't effectively generate binaries.

I have never really heard the name "two language problem" to refer to what you are describing. Whenever I have heard these words it has referred to "I want a high-productivity newbie-friendly introspective language like python, but I do not want to write C modules when I need fast inner loops". Julia seems to solve this already, without providing compact binaries.

A sibling comment made a point about "compiling down to shared libraries" which seems similar to what you are describing, but that seems like it has little to do with "the two language problem".

Re: Julia 1.6 addresses latency issues

#60

Post by Tainnor »

smabie wrote: post #51

So I used to be a big proponent of Julia, and in some ways, I still am. But I very recently tried to write a high performance production system in it, and was sorely disappointed. The tooling is just so buggy and it's clear that the community isn't really interested in using it for anything besides modeling/research in a Jupyter notebook. Things that kind of suck about using Julia for production: 1. Never could get R…

I would also add:

5. The module system is very primitive.

6. The testing framework is extremely barebones.

I agree with your assessment, Julia is great for crunching numbers etc., but I wouldn't write a whole application in it.

Post reply on HN