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

31–40 of 160 posts

Re: Julia 1.6 addresses latency issues

#31

Post by up6w6 »

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…

> 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 (its an official project) that is stuck. The common sense would be just list the web frameworks but I dont think its fair simply because there is no interest on it (yet).

Re: Julia 1.6 addresses latency issues

#32

Post by superdimwit »

reikonomusha wrote: post #28
krastanov wrote: post #21

Earlier quoted context omitted.

Could you elaborate or give examples? I guess all the complaints about binaries come from people used to something like Common Lisp, but while I have a general understanding of what a lisp is, this type of "provide a binary for your interpreted-ish language" is an incredibly foreign idea to me.

Common Lisp was designed to be interactive and have a REPL. You can redefine functions, classes, etc. on the fly with strictly-defined semantics. (You don’t have to guess what happens if you, say, re-name a field of your class.) This is insanely useful during development, where you absolutely want to avoid doing full recompiles every time you make a little change you want to test. Some people call this “interactive a…

I am hopeful that Julia should be able to get this cross-session caching of compiled code. Would make restarting the REPL (to e.g. add a field to a struct) much less frustrating.

Re: Julia 1.6 addresses latency issues

#33

Post by Zababa »

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…

> Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages?

I think this is the case for at least the most popular JIT'd languages: Java, C#, JS, and PHP. Also for the most popular interpreted languages: Python, Ruby and also PHP. I don't know about Visual Basic and R though.

I know that an exception is Dart, that combines a JIT and an AOT. I think EmacsLisp can now be also compiled, but I don't know if it works with all the code and is just free performance, or something more limited.

Edit: as pointed at by pjmlp, Java and C# already combine an AOT and a JIT. What I meant by the comment on Dart is that it can either be run with a VM or compiled to produce binaries.

Re: Julia 1.6 addresses latency issues

#34

Post by reikonomusha »

superdimwit wrote: post #32
reikonomusha wrote: post #28

Earlier quoted context omitted.

Common Lisp was designed to be interactive and have a REPL. You can redefine functions, classes, etc. on the fly with strictly-defined semantics. (You don’t have to guess what happens if you, say, re-name a field of your class.) This is insanely useful during development, where you absolutely want to avoid doing full recompiles every time you make a little change you want to test. Some people call this “interactive a…

I am hopeful that Julia should be able to get this cross-session caching of compiled code. Would make restarting the REPL (to e.g. add a field to a struct) much less frustrating.

Yeah, restarting a Lisp REPL after you’ve compiled your code is transparently essentially instantaneous, because everything is cached and checked for changes, and 99% of the time most of your code and nearly all of your dependencies aren’t changing hour to hour.

Re: Julia 1.6 addresses latency issues

#35

Post by thecupisblue »

ssivark wrote: post #3
gugagore wrote: post #2

It is amazing and frustrating to me how much latency affects my productivity. I wish I could more effortlessly switch between tasks, or just meditate and relax while I wait for something I just did on the REPL to finish. But I don't. More often than not, a 30-second delay to e.g. plot something destroys my ability to stay in a productive zone. I have been using Julia 1.6 since the release, and I'm so grateful not onl…

Very interesting UX observations on interactive programming. Kinda like mirrors in waiting areas, I wonder whether judicious logging messages about the compilation process (not a wall of text, but just enough) will serve to keep users engaged while also educating them about the compilation happening on the backend. That will help users feel more agency, and also improve their mental models of how to structure their c…

That actually helps. Talking from years of experience doing Android development, where in the early days (and still on some projects) you would have +5 minute rebuild time, and it's supper annoying to check minor things. Having more logs actually helped it seem faster, even tho it wouldn't be, but also you could know where you are stuck and why, which helps identify bottlenecks in build processes.

Sometimes it would be enough to just google what the long task does and see "oh wait I don't actually need that step for my daily development" (e.g. resource crunching, crash reporting initalization etc) or point you in the direction of "why isn't this caching itself".

Quite a useful thing, and should be available as an option at least. In a REPL it might be context noise, but should still be there as a --verbose option.

Re: Julia 1.6 addresses latency issues

#36

Post by KenoFischer »

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 promise ecosystem will not be considered complete until this fundamental problem is solved. That said, you can have time-to-first plot below a hundred milliseconds right now if you put Plots into your system image - that's always been an option. System images have workflow issues which is why they're not used more.

Re: Julia 1.6 addresses latency issues

#37

Post by clarkevans »

Buttons840 wrote: post #4

I'm a big fan of Julia. It does live up to its speed claims. I've implemented the board game Go in Python, Rust, and Julia and Julia is definitely closer to Rust in speed. Same algorithms were used for all implementations. Julia's time to first plot still has some problems. The Plots library can build animations, but the time to first animation on my computer is like 10 minutes, and the time to second animation is an…

Multiple dispatch and generic programming make Julia a productive language to work with. However, a given program may have unnecessary function specializations (which affect startup compile time) or unexpected dynamic dispatches (which affect runtime performance). These can be addressed with some important development patterns: checking for type stability via @code_warntype, using opaque structs or @nospecialize when appropriate, etc. I've found the Julia community to be very helpful with regard to performance on the forums, slack, and zulip.

Re: Julia 1.6 addresses latency issues

#38

Post by ku-man »

clarkevans wrote: post #37
Buttons840 wrote: post #4

I'm a big fan of Julia. It does live up to its speed claims. I've implemented the board game Go in Python, Rust, and Julia and Julia is definitely closer to Rust in speed. Same algorithms were used for all implementations. Julia's time to first plot still has some problems. The Plots library can build animations, but the time to first animation on my computer is like 10 minutes, and the time to second animation is an…

Multiple dispatch and generic programming make Julia a productive language to work with. However, a given program may have unnecessary function specializations (which affect startup compile time) or unexpected dynamic dispatches (which affect runtime performance). These can be addressed with some important development patterns: checking for type stability via @code_warntype, using opaque structs or @nospecialize when…

This is exactly the problem with Julia, to achieve those (soo much vaunted) c-like-speeds you need quite a few contortions.

Re: Julia 1.6 addresses latency issues

#39

Post by pjmlp »

Zababa wrote: post #33
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…

> Isn't "generating binaries" just as bad for other interpreted (interpeted-ish) languages? I think this is the case for at least the most popular JIT'd languages: Java, C#, JS, and PHP. Also for the most popular interpreted languages: Python, Ruby and also PHP. I don't know about Visual Basic and R though. I know that an exception is Dart, that combines a JIT and an AOT. I think EmacsLisp can now be also compiled, b…

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.

Re: Julia 1.6 addresses latency issues

#40

Post by enriquto »

KenoFischer wrote: post #36
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 promise ecosystem will not be considered complete until this fundamental problem is solved. That said, you can have time-to-first plot below a hundred milliseconds right now if you put Plots into your system image - that's always been an option. System images have workflow issues which is why they're not used more.

Sounds great, thanks! That is certainly reassuring to hear. I'm very happy to see Julia evolving.

EDIT: also, sorry for the mis-characterization of Julia developers! I may have dealt until now with users and "fanboys" not real devs.

Post reply on HN