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

101–110 of 160 posts

Re: Julia 1.6 addresses latency issues

#101

Post by krastanov »

neolog wrote: post #97
adgjlsfhk1 wrote: post #87

Earlier quoted context omitted.

One thing that would help a lot is if julialang.org offered downloads with a bunch of common packages baked into a sysimage (modeled roughly of of anaconda). My rough estimate of packages to include would be Plots, BandedMatrices, DifferentialEquations, CSV, DataFrames, Flux, PyCall, (and probably some others). Having a distribution with a lot of the heavy hitter built in would make workflows using those packages muc…

Are there some lists of most-downloaded packages?

By github stars: https://juliahub.com/ui/Packages

There are better stats available (downloads), but I do not know of a good place to play with them publicly.

Re: Julia 1.6 addresses latency issues

#102

Post by m_mueller »

pythrowaway wrote: post #94
xiaodai wrote: post #77

Earlier quoted context omitted.

What you've pointed out might all be valid. But they seem to be issues with maturity. When Python was at a similar age, did it have all these issues worked out? Not sure if you can generalize it to "Julia community isn't interested". If we have more ppl liking Julia and using it for general purpose computing (which it is capable of), then more of these tools will become mature overtime. Also, Julia is not in the same…

Problem for Julia is, the Python ecosystem gets better every year. Python might be getting better faster than Julia can catch up.

I highly doubt it for one core feature: performance. For a little while it looked like Python 4 might fix this (by using type hints to JIT) , but it was quickly given up. IMO a big shame as it is the one thing holding python back.

Re: Julia 1.6 addresses latency issues

#103

Post by pjmlp »

pythrowaway wrote: post #94
xiaodai wrote: post #77

Earlier quoted context omitted.

What you've pointed out might all be valid. But they seem to be issues with maturity. When Python was at a similar age, did it have all these issues worked out? Not sure if you can generalize it to "Julia community isn't interested". If we have more ppl liking Julia and using it for general purpose computing (which it is capable of), then more of these tools will become mature overtime. Also, Julia is not in the same…

Problem for Julia is, the Python ecosystem gets better every year. Python might be getting better faster than Julia can catch up.

Julia runs fast enough to catch Python, because Python will never improve the main reason why Julia was created in first place, the community embracing a JIT compiler instead of re-writing working code into C.

Re: Julia 1.6 addresses latency issues

#104

Post by oscardssmith »

m_mueller wrote: post #102
pythrowaway wrote: post #94

Earlier quoted context omitted.

Problem for Julia is, the Python ecosystem gets better every year. Python might be getting better faster than Julia can catch up.

I highly doubt it for one core feature: performance. For a little while it looked like Python 4 might fix this (by using type hints to JIT) , but it was quickly given up. IMO a big shame as it is the one thing holding python back.

I think Julia actually does a pretty good job of showing that the problem isn't types. The problem is semantics. Julia's restriction is eval to the global scope is a perfect example of this. It has a pretty minor on code, but a massive effect on performance. Python has a ton of things like this where a slightly different (and totally breaking) semantic change prevents optimization.

Re: Julia 1.6 addresses latency issues

#105

Post by DNF2 »

enriquto wrote: post #55
DNF2 wrote: post #52

Earlier quoted context omitted.

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.

It think that the discussions on HN tend to be quite combative, and members of the Julia community (including myself) can get a bit worked up over negative claims that we find overly sweeping. That could lead to some dismissiveness.

I do get frustrated by characterizations of the interests of the Julia community that are very broad, and are also in evidence here. E.g. somewhere upthread one person claimed Julians are only interested in Jupyter Notebook workflows, which is a totally alien statement to me. Jupyter doesn't seem to have a very large mindshare as far as I can tell, I've never even tried it myself.

Static compilation and analysis comes up regularly on Discourse, but among the scientist part of the community, there is naturally less emphasis on this. Please don't extrapolate too far based on some isolated interactions.

Re: Julia 1.6 addresses latency issues

#106

Post by oscardssmith »

lmm wrote: post #99
cjalmeida wrote: post #95

Earlier quoted context omitted.

I’ve implemented some graph traversing algos in Julia and 100x faster than Python. Really in the same ballpark of C++, but much simpler code.

> 100x faster than Python. Really in the same ballpark of C++, but much simpler code. One could say the same for any of the languages I listed (maybe not "much simpler code" in the case of Java).

If you want a harder guarantee, well written numerical code will be as fast as any other language. If you find a counter example, let us know (it's probably something that should be fixed).

For string processing and other gc heavy code, Julia has further to go. Julia's gc is pretty basic, and needs a lot of love. That said, for dataframes like workloads, Julia usually manages to hand with the best (data.table), and it's rarely much slower.

Re: Julia 1.6 addresses latency issues

#107

Post by lmm »

oscardssmith wrote: post #106
lmm wrote: post #99

Earlier quoted context omitted.

> 100x faster than Python. Really in the same ballpark of C++, but much simpler code. One could say the same for any of the languages I listed (maybe not "much simpler code" in the case of Java).

If you want a harder guarantee, well written numerical code will be as fast as any other language. If you find a counter example, let us know (it's probably something that should be fixed). For string processing and other gc heavy code, Julia has further to go. Julia's gc is pretty basic, and needs a lot of love. That said, for dataframes like workloads, Julia usually manages to hand with the best (data.table), and i…

My assumption is that there's nothing outstanding or remarkable about Julia's performance. Comparing to Python/Perl/Ruby/TCL is a good way to make any language seem fast, and comparing to C++ is a good way to make any language seem expressive. I'd be far more interested to hear about comparisons with alternatives that might actually be competitive - non-scripting languages with a reputation for being expressive, such as ML-like functional languages, or recent general-purpose languages like Swift/Kotlin/C#.

Re: Julia 1.6 addresses latency issues

#108

Post by diragon »

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…

How did you cope with the lack of REPL on Rust's side?

Re: Julia 1.6 addresses latency issues

#109

Post by Mauricebranagh »

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…

Well as one of the aims as I understand it for Julia was as an alternate to Fortran.

You should consider your self lucky when I started the compile link process took a while and that is assuming you had real time access.

I recall one of my colleagues who was running her code on an ICL at AWE (Underwater Weapons Establishment) coming into the terminal room logging in and sighing "48 jobs in GEORGE ahead of hers.

A year later we brought a Pr1me Super Mini which made things a lot faster.

Re: Julia 1.6 addresses latency issues

#110

Post by globular-toast »

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…

This is why git was such a game changer. Making a commit to SVN took a considerable amount of time, especially back in the day on slow internet connections. Making a commit with git is generally instant and doesn't break flow. It changes the way you work. People used to avoid committing with SVN, sometimes doing it only once a day. That seems completely insane now.

I have very little tolerance for latency in my tools. It's one of the top deciding factors for me when choosing which tools to use. It's that important.

Post reply on HN