Hacker News Reader

Hacker News

Comment by adgjlsfhk1 | Hacker News Reader

Full thread

adgjlsfhk1

A quick list of other nice things in the release.

Performance:

* faster hashing for a variety of types (Array, Symbol, and a few others)

* faster ldiv! for QR factorizations

* faster findall for AbstractArray

* faster expm, log2, and log10

* faster isless for floats

* faster @fastmath versions of exp, exp2, exp10

* faster cbrt, sinh, exp for Float16

* Improved array resizing on push!

Features

* Exact determinants for BigInt matrices

* lpad/rpad now use text-width instead of bytes

* Make it significantly easier to use MKL (or other BLAS libraries)

* opaque closures (complicated mostly internal feature)

I'm sure I've missed a bunch in this list (I compiled it by scanning through the commit list)

View on HN

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.

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.

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?

Some of those features seem wild to me, aren't ldiv,exp,log2, isless and fastmath stuff basically just "map to what Intel have given us"? I'm amazed how low level these functions are.

the Intel processor intrinsics are almost all completely broken. there are relatively good libm implementations, but packaging them is a nightmare, as is ensuring good performance across architectures. also in my experience, the Julia versions tend to have better performance.

We often can do better than what Intel gives us, so we do. It takes a lot of time, but slowly lots of low level functions that are taken to be intrinsics by most languages are getting written in pure, high performance julia.

Reply on news.ycombinator.com