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

11–20 of 160 posts

Re: Julia 1.6 addresses latency issues

#11

Post by krastanov »

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 making binaries (and I would say that about python and perl too).

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?

Re: Julia 1.6 addresses latency issues

#12

Post by enriquto »

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 that you are "holding it wrong" and that this is not really a problem, that your usage is "niche", that the interpreter is alright as it is, and that the time to first plot is unlikely to ever go below a hundred milliseconds. I find it really depressing for the language itself is incredibly beautiful. My only hope is that an independent, fast and unix-friendly implementation of the language arises, thus freeing the reference implementation of the efficiency burden and allowing it to be simpler. Something like the lua/luajit split.

Re: Julia 1.6 addresses latency issues

#13

Post by krastanov »

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…

> the time to first plot is unlikely to ever go below a hundred milliseconds

How is that controversial or disappointing!? Why would anyone bother optimizing this? Nor is matlab/octave/python any faster.

`python3 -c "import matplotlib.pyplot as plt; plt.plot([1,2,3]);"` takes 600ms on my (powerful) workstation and that does not even include creating the plot window.

To be clear, I do believe there is much more work to be done to decrease latency in Julia, but your targets are ridiculous. And as a regular on their bugtracker and forum, the devs definitely acknowledge these issues and have many times said it is one of their main priorities.

By the way, if you want streaming live updated plots, this latency to first frame is not a problem. It is already straightforward to make such fast live plots in Julia (although it does not fit my personal taste for how to do it).

Re: Julia 1.6 addresses latency issues

#14

Post by enriquto »

krastanov wrote: post #13
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…

> the time to first plot is unlikely to ever go below a hundred milliseconds How is that controversial or disappointing!? Why would anyone bother optimizing this? Nor is matlab/octave/python any faster. `python3 -c "import matplotlib.pyplot as plt; plt.plot([1,2,3]);"` takes 600ms on my (powerful) workstation and that does not even include creating the plot window. To be clear, I do believe there is much more work to…

> your targets are ridiculous

Only because you are not used to somewhat fast programs:

    $ /usr/bin/time -v gnuplot -e 'set term png; plot sin(x)' > sin.png
    ...
    User time (seconds): 0.02
    System time (seconds): 0.00

Re: Julia 1.6 addresses latency issues

#15

Post by sgt101 »

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'm not saying you are wrong - but why 100ms and not 50ms or 200ms or 2000ms?

Re: Julia 1.6 addresses latency issues

#16

Post by krastanov »

enriquto wrote: post #14
krastanov wrote: post #13

Earlier quoted context omitted.

> the time to first plot is unlikely to ever go below a hundred milliseconds How is that controversial or disappointing!? Why would anyone bother optimizing this? Nor is matlab/octave/python any faster. `python3 -c "import matplotlib.pyplot as plt; plt.plot([1,2,3]);"` takes 600ms on my (powerful) workstation and that does not even include creating the plot window. To be clear, I do believe there is much more work to…

> your targets are ridiculous Only because you are not used to somewhat fast programs: $ /usr/bin/time -v gnuplot -e 'set term png; plot sin(x)' > sin.png ... User time (seconds): 0.02 System time (seconds): 0.00

Come on, it is silly to compare a full general purpose language against a special-purpose tool. Yes, grep is also better than julia at searching for a string in a file.

Julia is a terrible replacement for gnuplot and gnuplot is a terrible replacement for julia.

Re: Julia 1.6 addresses latency issues

#17

Post by reikonomusha »

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…

It’s not at all bad for Common Lisp, which is a superlatively interactive language.

Re: Julia 1.6 addresses latency issues

#18

Post by adgjlsfhk1 »

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…

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 libraries. Furthermore, this capability is likely crucial in getting major further improvement in time to first plot. Currently `@time DifferentialEquations` takes about 11 seconds on my computer, but if more of the code could be statically compiled at precompile time, that could be reduced dramatically.

Re: Julia 1.6 addresses latency issues

#19

Post by enriquto »

krastanov wrote: post #16
enriquto wrote: post #14

Earlier quoted context omitted.

> your targets are ridiculous Only because you are not used to somewhat fast programs: $ /usr/bin/time -v gnuplot -e 'set term png; plot sin(x)' > sin.png ... User time (seconds): 0.02 System time (seconds): 0.00

Come on, it is silly to compare a full general purpose language against a special-purpose tool. Yes, grep is also better than julia at searching for a string in a file. Julia is a terrible replacement for gnuplot and gnuplot is a terrible replacement for julia.

Sure! That's why I set a somewhat reasonable target at being just 5x or 10x times slower than a specific-purpose plotting tool. But even that is considered to be chimerical! (or, in your words, "ridiculous")

Re: Julia 1.6 addresses latency issues

#20

Post by reikonomusha »

krastanov wrote: post #16
enriquto wrote: post #14

Earlier quoted context omitted.

> your targets are ridiculous Only because you are not used to somewhat fast programs: $ /usr/bin/time -v gnuplot -e 'set term png; plot sin(x)' > sin.png ... User time (seconds): 0.02 System time (seconds): 0.00

Come on, it is silly to compare a full general purpose language against a special-purpose tool. Yes, grep is also better than julia at searching for a string in a file. Julia is a terrible replacement for gnuplot and gnuplot is a terrible replacement for julia.

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.
Post reply on HN