Hacker News Reader

Comment by Buttons840 | Hacker News Reader

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 another 10 minutes. Probably just a bug, I haven't found any other case that takes so long.

I've also mentioned before that a reinforcement learning algorithm I ported from Python/PyTorch to Flux was faster, not because of training times, but because of all the other stuff (and RL has more "other stuff" than supervised learning) that goes on outside the core training loop is so much faster.

View on HN

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.

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

I don't think those contortions are all that crazy compared to what you have to do in C though anyways. And you can choose where to spend your effort in optimizing functions.

Sometimes, a function really is performance critical so you spend a ton of time fiddling with it to make it blazing fast, other times you write something non-optimal but straightforward. It's all the same language though, and unlike tools like Cython, you don't lose all your nice high level language features when you drop down to 'high performance julia code'.

> I've implemented the board game Go in Python, Rust, and Julia and Julia

Oof. I reread this several times consecutively as "I've implemented the board game in Go, Python, Rust ...".

Same, and I literally have a correspondence game going on in another tab

what's your ogs id? I challenge u

ID is Ada Countess of Lovelace. What's yours.

> 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.

"Closer to Rust than to Python" is a wide range. Almost any non-scripting language (e.g. Java, OCaml, Haskell, Dylan...) would qualify, and that's normally not enough to give them a reputation as "fast".

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.

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#.

If you want performance benchmarks vs Fortran, https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packa... has benchmarks with Julia out-performing highly optimized Fortran DiffEq solvers, and https://github.com/JuliaLinearAlgebra/Octavian.jl shows that pure Julia BLAS implementations can compete with MKL and openBLAS, which are among the most heavily optimized pieces of code ever written. Furthermore, Julia has been used on some of the world's fastest super-computers (in the performance critical bits), which as far as I know isn't true of Swift/Kotlin/C#.

Expressiveness is hard to judge objectively, but in my opinion at least, Multiple Dispatch is a massive win for writing composable, re-usable code, and there really isn't anything that compares on that front to Julia.

> If you want performance benchmarks vs Fortran, https://benchmarks.sciml.ai/html/MultiLanguage/wrapper_packa... has benchmarks with Julia out-performing highly optimized Fortran DiffEq solvers, and https://github.com/JuliaLinearAlgebra/Octavian.jl shows that pure Julia BLAS implementations can compete with MKL and openBLAS, which are among the most heavily optimized pieces of code ever written.

That seems to be very Julia-specific comparisons, which I'm sure will be oriented towards the use cases Julia has been designed for. I'm more interested in "neutral" benchmarks and more general-purpose computing areas.

> Furthermore, Julia has been used on some of the world's fastest super-computers (in the performance critical bits), which as far as I know isn't true of Swift/Kotlin/C#.

That's more a reflection of culture than performance though. Back when I worked with a bunch of data scientists they would happily run Python or R on our Spark cluster, consuming oodles of resources to do not very much, but balked at writing Scala, even though their code would have run much faster.

That's fair. That said, the fact that writing a BLAS implementation in a high level language seems like a favorable benchmark does kind of show my point that for numerical computing, Julia is really fast (especially for a high level language).

As a general purpose language, I'd probably categorize Julia as fast, but not crazy fast. Numerical computing is definitely where most of the man hours have gone into development. As a general purpose language, Julia probably ends up at around the same place as C# (not as fast as C++, but still pretty respectable). That said, this is an area where the main thing Julia needs here is more optimization on some of the libraries that already exist, and some new libraries to extend the language's reach further. I don't think there's anything fundamental holding it back from getting closer to C++ performance in general computing. It uses the same compiler (LLVM), and it's pretty clear that you can get Julia to output the same assembly code. It's just a matter of having enough devs pushing ecosystem forward.

For a non-numerical benchmark where Julia does really well, you should also check out https://h2oai.github.io/db-benchmark/. There's a bunch of work to be done to improve DataFrames.jl more, but it's already one of the fastest tools for what it does (despite having only reached version 1.0 a few weeks ago).

Ok, that's a little more interesting - a "neutral" benchmark of several tools, though still very much in a niche use case.

Is there any effort to include Julia in the TechEmpower Benchmarks? If it's trying to be a general-purpose language, that's the first place I'd look.

It's already on there for some of the benchmarks at least. It generally is roughly between 30th and 60th place depending on the benchmark (with outliers in both directions). That said, HTTP.jl is not a library that has had a ton of work in Julia, and it's probably not what you want to write a high performance webserver in at the moment. I don't think this is a fundamental limitation, but just a domain that needs a couple thousand dev hours to make competitive with some of the more mature frameworks. Another part of the problem is that Julia has some fairly well known garbage collection performance problems. GC performance hasn't been a major dev priority as of yet, since the language is much better than most high level languages at eliding allocations or stack allocating variables (so it doesn't make as much garbage for many workflows). That said, for GC heavy tasks (string stuff often is), it is a major problem that is starting to get a bunch of effort put into it. Hopefully in a year or 2, these issues will be solved. It's nothing too fundamental, just that the current GC only has 2 generations, and the heuristics for moving objects between generations are not tuned especially well.

Do you have any documentation / Github repos where you build those Go implementations? I am a huge fan of the game and would be curious to see how you built it, specifically in Python / Julia.

https://github.com/DevJac/gobot https://github.com/DevJac/julia_gobot

> but the time to first animation on my computer is like 10 minutes

Have you tried 1.6 already? I find it's substantially faster.

Yes, I was doing it just this week with Julia 1.6.

what's your ogs id? I challenge u

Reply on news.ycombinator.com