Making Julia as Fast as C++ (2019)

dd_tr 3 days ago 16 commentsRead Article on flow.byu.edu

DE version is available. Content is displayed in original English for accuracy.

⚡ Community Insights

Discussion Sentiment

91% Positive

Analyzed from 597 words in the discussion.

Discussion (16 Comments)Read Original on HackerNews

StilesCrisis•about 2 hours ago

Punchline: rewrote the code to look almost identical to C++, hand-held the compiler by adding @-marks to disable safety checks, forced SIMD codegen and fastmath on.

End result: code that is uglier and still much slower than C++. Kind of a shame.

SatvikBeri•about 1 hour ago

This is 7 years old. Julia is a totally different language by now.

As a quick anecdote, in our take-home interview exercise, we usually receive answers in C++ or Julia, and the two fastest answers have been in Julia.

HarHarVeryFunny•about 1 hour ago

I'd have to guess that this is because of ease of use. C++ lets you get as close to the metal as you choose to, so there is no reason why a C++ solution shouldn't be at least as fast as one written in any other language, and yet ...

Of course it also depends on what additional libaries you are using, especially when it comes to parallel/GPU programming in C++, but easy to believe that Julia out of the box makes it easy to write high performance parallel software.

d_tr•about 1 hour ago

> This is 7 years old.

Yeah, I actually totally forgot to check the date...

neutrinobro•about 1 hour ago

Hardly seems worth the effort, perhaps things have improved since 2019. It would be interesting to see an updated benchmark, but if your going to end up with code that looks like C++ to get proper performance, you might as well write it in C++. My biggest problem with Julia is that they decided to use column-major indexing for multi-dimensional arrays (i.e. FORTRAN/MATLAB style). This makes interoperability with C/C++ and python numpy a real pain, since you can't do zero-copy array sharing between the two without one side being forced into strided-access. For that reason alone I haven't adopted it in any of my work-flows.

brabel•about 2 hours ago

> code that is uglier and still much slower than C++.

Oh such a shame indeed! They didn’t even manage to produce better looking code at least?? Julia was looking great in 2019 but it was very buggy still so I stopped looking. Had hopes that by now it would be a good choice over C++ and Rust with similar performance.

cmrdporcupine•about 2 hours ago

There's simply no way it'd ever have similar performance to those. It's not possible.

I have always seen it as a potential alternative to Java, and definitely better than Python.

My experience working in it professionally was that it was... fine. But the GC in it was not good under load and not competitive with Java's.

2ndorderthought•about 1 hour ago

How hard was it to maintain a large Julia code base rather then say an OOP or Rust one? It has an interesting paradigm. I feel like it could get really messy

2ndorderthought•about 2 hours ago

I don't get the appeal. It's like a. OSS Matlab but all contributions are used directly so the language developers can make money for a parent company? Most OSS languages aren't run that way. Seems kind of scammy

postflopclarity•1 minute ago

the parent company is a consumer of Julia, and has no formal role in oversight or governance; they are of course invested in the success and performance of the language, but so are all other users!

andyferris•14 minutes ago

Meh, I’ve never been associated with the company and AFAICT they provide value through platforms for enterprises. Not everyone gets OSS sponsorships to fund team (and using a social media presence to achieve this was a post-Julia phenomenon).

It’s nothing like Google-the-ad-company influencing Chrome. The company consumes Julia for products to sell, rather. Maybe this affects the ordering of features landing, but… meh.

ForceBru•about 3 hours ago

Recent discussion on Julia Discourse: https://discourse.julialang.org/t/making-julia-as-fast-as-c/

FattiMei•about 2 hours ago

Very interesting post and I think this exposes the limitations of the Julia compiler. Note that an old version of the compiler is used (1.0.3 from 2019).

One could say that we can almost replicate the semantic of a C++ program, but writing in Julia. For example we can remove bounds checks in arrays or remove hidden memory allocations.

But the goal of a language for numerical computing is capturing the mathematical formulas using high level constructs closer to the original representation while compiling to efficient code.

Domain scientists want to play with the math and the formulas, not doing common subexpression elimination in their programs. Just curious to see how it evolves

northzen•about 2 hours ago

I think the best compromise would be to get the best of two words. By default perform bound checks, but have a compiler flag which skips it. Might broke many programs written with default behaviour in mind, but allow perform additional optimizations.

postflopclarity•18 minutes ago

this is exactly what julia does. boundschecks are default on, and there are compiler flags --- either locally, via the `@inbounds` macro, or globally with `--check-bounds=no`--- to disable them

slwvx•3 days ago

From 2019