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.
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
Dang, haven’t read much on Julia as of late. I remember using it for a CS 300-level course around 2016 when learning about tokenizing and parsing as part of language fundamentals. Julia has undoubtedly made some significant performance improvements since then. Would love to see a follow-up that explores what, if anything, from this still holds true and what improvements can be made.
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 intention is not write scripts, but high performance numerical/scientific code, and with Julia's JIT-based design, rapid iteration (to me at least) feels slower than Rust (!).
I wonder how Mojo ranks along with Julia. Mojo was discussed yesterday here. Mojo seems to be more python focused while Julia is very much focused on Scientific computation. I may be wrong.
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.
Julia is reasonably fast. I returned to a language comparison project specific to my math research, to see how I might do better. My agents and I studied the advice in the post and various more recent links from the comments, but we were already mostly on target and nothing left moved the needle.
My work is more combinatorial. Julia does excel at numerical computation. There's a tribal divide in math between people who can't go 30 seconds away from the real or complex numbers, and those whose tolerance is about that long. I try to keep an open mind, but I'm closer to the second camp. Julia is good enough to consider either way.
A development in recent months, AI can assist in general purpose Lean 4 programming, no longer getting confused by the dominant proof-oriented training corpus. If one is a functional programmer who believes that Haskell was on the right track, then Lean is the most interesting language choice for shaping one's thoughts. Benchmarks are inherently misleading if a better language makes it possible to express algorithms out of reach of more primitive languages.
Over the years there already was almost the identical articles about making in language X program as fast as C or C++... And results was exactly the same: write C/C++ style programs!
Why ?
Because of CPU's architecture - given CPU one just need to structure code in a way CPU can perform efficiently! Is it such surprising that all sugar and multi-functional smartness have cost of all that if's and loops like maps? CPU is just rock stupid and can't do anything else!
That's from where all that specialized instructions are coming and programs just need to be structured or compiled to CPU arch way to perform as fast as CPU and rest of hardware allows...
And there are some "Java machines" and that is exaclty the same story: use CPU native lang :) As much as posible.
14 comments
[ 5.3 ms ] story [ 30.7 ms ] threadEnd result: code that is uglier and still much slower than C++. Kind of a shame.
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
Prelude of what's to come in the self-reinforcing cycle of machines talking to machines and drowning everything else.
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 intention is not write scripts, but high performance numerical/scientific code, and with Julia's JIT-based design, rapid iteration (to me at least) feels slower than Rust (!).
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/
My work is more combinatorial. Julia does excel at numerical computation. There's a tribal divide in math between people who can't go 30 seconds away from the real or complex numbers, and those whose tolerance is about that long. I try to keep an open mind, but I'm closer to the second camp. Julia is good enough to consider either way.
A development in recent months, AI can assist in general purpose Lean 4 programming, no longer getting confused by the dominant proof-oriented training corpus. If one is a functional programmer who believes that Haskell was on the right track, then Lean is the most interesting language choice for shaping one's thoughts. Benchmarks are inherently misleading if a better language makes it possible to express algorithms out of reach of more primitive languages.
https://github.com/Syzygies/Compare
- not a single post has anything inside here https://flow.byu.edu/posts/
Why ?
Because of CPU's architecture - given CPU one just need to structure code in a way CPU can perform efficiently! Is it such surprising that all sugar and multi-functional smartness have cost of all that if's and loops like maps? CPU is just rock stupid and can't do anything else!
That's from where all that specialized instructions are coming and programs just need to be structured or compiled to CPU arch way to perform as fast as CPU and rest of hardware allows...
And there are some "Java machines" and that is exaclty the same story: use CPU native lang :) As much as posible.
So: give us better cpus pls :)