Hacker News Reader

Comment by vletal | Hacker News Reader

Are these really the pain points of the language needed to be addressed? What kills me specifically is the fact how sloooow are the initial warm-ups. I am forced to write a webserver in Julia. The startup time is ~5min and each initial request takes like 45s. The lengths I needed to go and the hacks I needed to do to reduce that are mesmerising.

Faster log10 is all nice but I would love to see a more aggressive compilation cache and improved tooling rather than these minor improvements.

View on HN

That list is not a representative example of what the core devs are doing. It looks to me like it's mostly the work of Oscar Smith, he does a lot of these low-level numerical optimizations.

Here are a few more improvements in v1.7 off the top of my head:

* Further latency improvements (though much smaller than for 1.6)

* Big gains in inference precision for the compiler

* The above also unlocks better static analysis

* Improved speed for the package manager on Windows

* Begin work on adding atomics

* Thread-safe RNG

I'm sure there is more I've missed - I don't hack on Base Julia much.

I meant to add the atomics work to this. (I didn't mention the rng since it was already in the article). The others are important, but a bit harder to quantify (and harder to find from scanning the commits).

Wait didn't we get thread safe RNG a few minor releases ago? At least for the default global rng?

I agree. More work on latency, pre compilation and PackageCompiler is sorely needed. Julia is also behind on the version of LLVM that is being used, and apparently they are regressions in performance with newer versions. The fact that performance is an implementation detail is concerning, and it would be nice to standardize some of the language.

However, I think it is unfair to compare the inclusion of log10 to the work required to get solutions to these harder problems. I guess why not both? ;)

> Julia is also behind on the version of LLVM that is being used,

Julia 1.6 (LLVM 11) and Julia 1.7 (LLVM 12) use the LLVM versions that were current, when the release branch was cut. LLVM 13 was finalized a fes days ago and will be released this week.

So I am not sure where the notion comes from that Julia is lagging behind.

> apparently they are regressions in performance with newer versions

There are? I mean, with every new LLVM release a few things gets faster and a few things slower but I am not aware of any big changes in the recent LLVM releases. Do you have any more information about that?

I like Julia a lot, but out of curiosity why are you writing a web server in it? I would 100% reach for Python for that use case.

I'm not OP, but I can easily see my team getting into the same situation.

Our use case involves dynamically displaying some analysis results on a status page derived from data from the field. The analysis was originally written in Python + scipy + matplotlib (Julia in OP's case). Why write the analysis code a second time just to display it on a demand-generated webpage?

You don't have to run the entire website on Julia, but maybe you do want to stand up a couple of RESTful endpoints that are integrated with the rest of the web application. If Julia can't do that, then your options will be limited.

That makes sense.

Exactly. We are training a very large neural model using [1]. We would not fix much if we decided to embed the Julia code inside a CPython wrapper or something...

[1] https://github.com/CTUAvastLab/JsonGrinder.jl

a lot of work is going into these areas, but most of it isn't work that happens in Base. over the past 6 months or so, a fair number of the important big packages have gotten a bunch faster to load. also 5 minutes for webserver startup isn't my experience I'm writing an admittedly small one and it only takes a few seconds to start.

Reply on news.ycombinator.com