Making Julia as Fast as C++ (2019) • Hacker News Board

Re: Making Julia as Fast as C++ (2019)

#41

Post by celrod » Sat, May 09, 2026, 4:28 PM UTC

arbitrandomuser wrote: post #35

celrod wrote: post #34

Earlier quoted context omitted.

I'm still working on it. I'm currently working on a cache tile-size optimization algorithm that should (a) handle trees (a set of loops can be merged at some cache levels and split at others, e.g. in an MLP it may carry an output through the L3 cache, while doing sub-operations in the L2/L1/registers) (b) converge reasonably quickly so compile times are acceptable. This is the last step before I move to code generati…

oh , is it closed source now ? i couldnt find it on github anymore , github.com/LoopModels returns a 404.

Yeah, for now. I'd like it to be open, but I also want to potentially be able to make money/a living off of it. My dream would be that it can be open while hardware vendors pay me to optimize for their hardware. For how, being closed gives me more options. It's a lot easier to open in the future than to close, so it's just keeping options open.

I've thought a lot more about the engineering than any sort of marketing or businesses plan, so I just want to defer those.

Re: Making Julia as Fast as C++ (2019)

#42

Post by tombert » Sat, May 09, 2026, 4:40 PM UTC

kmaitreys wrote: post #28

I really like Julia as a language but I have struggled to adopt it and be productive in it. Part of it is because of the JIT runtime and a sub-par LSP (at least when I last tried). To those who regularly write Julia code, what is your workflow? The whole thing with Revise.jl did not suit me honestly. I have enjoyed programming in Rust orders of magnitude more because there's no run time and you can do AOT. My intenti…

Just an FYI...Claude is actually really good at building LSP servers [1].

If you want a better Julia LSP, you might just be able to get Claude or Codex to build one for you. I've been impressed with the TLA+ bindings it generated.

[1] https://github.com/Tombert/TLA-Language-Server-Protocol

Re: Making Julia as Fast as C++ (2019)

#43

Post by drnick1 » Sat, May 09, 2026, 4:53 PM UTC

StilesCrisis wrote: post #5

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.

Came here to say that. It's just easier to write C++ in the first place, and LLMs now make this easier than ever.

Re: Making Julia as Fast as C++ (2019)

#44

Post by csvance » Sat, May 09, 2026, 4:54 PM UTC

neutrinobro wrote: post #13

StilesCrisis wrote: post #5

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.

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+…

Just reverse the axis on one side, typically the Julia side. This is the convention used in Lux.jl/Flux.jl. I share memory between the two with zero additional copying for my workflows on a daily basis. If you are really allergic to doing this, I’m sure it’s possible to use metaprogramming / the type system to write it the same way in both places with zero performance overhead.

Re: Making Julia as Fast as C++ (2019)

#45

Post by mgkuhn » Sat, May 09, 2026, 5:34 PM UTC

I'm always surprised when people describe Julia syntax as "Pythonic": Julia's syntax was clearly inspired by MATLAB rather than Python.

And that's a good thing, because Python+NumPy syntax is far more cumbersome than either Julia or MATLAB's.

You can see this at a glance from this nice trilingual cheat sheet:

https://cheatsheets.quantecon.org/

Re: Making Julia as Fast as C++ (2019)

#46

Post by paddim8 » Sat, May 09, 2026, 5:43 PM UTC

kmaitreys wrote: post #28

I really like Julia as a language but I have struggled to adopt it and be productive in it. Part of it is because of the JIT runtime and a sub-par LSP (at least when I last tried). To those who regularly write Julia code, what is your workflow? The whole thing with Revise.jl did not suit me honestly. I have enjoyed programming in Rust orders of magnitude more because there's no run time and you can do AOT. My intenti…

What's the problem with the JIT runtime? Why is rapid iteration slower with JIT? Just-in-time compilation isn't inherently slower and is normally faster than AOT for dynamic languages and even static languages that have some dynamic features like dynamic dispatch

Re: Making Julia as Fast as C++ (2019)

#47

Post by mgkuhn » Sat, May 09, 2026, 5:45 PM UTC

Note that this article is about Julia 1.0.3, whereas today you should consider as obsolete any experience reports involving Julia versions prior to Julia 1.10 (the current LTS version), the most significant milestone in the maturity and usability of the language.

Re: Making Julia as Fast as C++ (2019)

#48

Post by SatvikBeri » Sat, May 09, 2026, 5:46 PM UTC

HarHarVeryFunny wrote: post #15

SatvikBeri wrote: post #11

Earlier quoted context omitted.

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.

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 ea…

Yes, with unlimited development time I would expect C++ solutions to be as fast or faster. But Julia hits a really nice combination of development speed and performance that I haven't found in other languages, at least for number crunching and data pipelines.

Re: Making Julia as Fast as C++ (2019)

#49

Post by SatvikBeri » Sat, May 09, 2026, 5:51 PM UTC

kmaitreys wrote: post #28

I really like Julia as a language but I have struggled to adopt it and be productive in it. Part of it is because of the JIT runtime and a sub-par LSP (at least when I last tried). To those who regularly write Julia code, what is your workflow? The whole thing with Revise.jl did not suit me honestly. I have enjoyed programming in Rust orders of magnitude more because there's no run time and you can do AOT. My intenti…

Well, my workflow uses Revise.jl. I develop either in Jupyter notebooks or in the REPL, prototyping code there and then moving functions to files when they're ready. In that context, rapid iteration is fairly fast.

Nowadays I often use Claude Code, working with a Julia REPL in a tmux or zellij session via send-keys. I'll have it prototype and try to optimize an algorithm there, then create a notebook to "present its results", then I'll take the bits I like and add them to the production codebase.

Re: Making Julia as Fast as C++ (2019)

#50

Post by SatvikBeri » Sat, May 09, 2026, 5:54 PM UTC

mgkuhn wrote: post #45

I'm always surprised when people describe Julia syntax as "Pythonic": Julia's syntax was clearly inspired by MATLAB rather than Python. And that's a good thing, because Python+NumPy syntax is far more cumbersome than either Julia or MATLAB's. You can see this at a glance from this nice trilingual cheat sheet: https://cheatsheets.quantecon.org/

It's definitely closer to matlab than python, but it's closer to python than most mainstream programming languages. I ported ~20k lines of python code to Julia over a couple years manually, and for the most part could do line-by-line translations that worked (but weren't necessarily performant until I profiled and switched to using Julia idioms.)