So, this morning I have asked Claude to convert our 12 years of development, large C++ simulation model in julia.
I have still to check it properly of course, but these are the initial outcomes. Very surpriced to see Julia much faster/efficient than C++
What if you asked Claude to improve the performance of the C++ code as well? 
Then repeat.
I calculate about 6.3x speedup, great, but not largest I’ve seen for AI rewrite! Even for $10.64 with EvoX Genesis. There seemingly 6.41× speedup is correct, but unfair comparison to your speedup, since only a subcomponent (you might have even higher speeup somewhere, have you dug into where and why faster?), and the “End-to-end benchmark: .. runs 1.25–1.32× faster than Fortran with exact integrator parity” seems more justifiably comparable to your speedup.
Can you say which Claude? Like Claude Code presumably, and Opus 5.5 and/or Fable 5.1? I’m not sure you can use Claude code with two models at the same time as with EvoX (or Devin Fusion). Do you know cost or tokens spent?
And do you want to say anything about code size? What does that 3.0 GB refer to, max RAM use?
1.55–6.87× median speedup, Fortran → Rust
89,946 lines of Rust replacing 139,414 lines of Fortran; 1,052 tests with 0 failures; a median speedup of 1.55–6.87×.
At GitHub I see:
Highlights
- ~67K LOC of pure Rust library code (129 files, 13 crates),
#![forbid(unsafe_code)]everywhere — zerounsafe, zero FFI.- ~1050 tests green (
cargo test --workspace→ 1052 passed / 0 failed / 18 ignored), including golden tests ported from the original Fortrantest_outputfiles (bit-exact or ~1e-9).- No LAPACK/BLAS FFI — matrix solvers (dense/banded/tridiag/block-tridiag/ sparse LU), ODE integrators (dopri5, dop853, ros2, rodas*), bicubic/bipm interpolation, and the approx21 network with analytic Jacobian are all pure-Rust ports.
- End-to-end benchmark: the net 1-zone burn pipeline (approx21, the project’s end-to-end proxy) runs 1.25–1.32× faster than Fortran with exact integrator parity (nstep 199 / naccpt 198 / nrejct 1 / nfcn 8889 / njac 199).
“Every workload is faster than the original Fortran.” though seemingly fastest only | num_newton (10K solves) | 0.057918 | 0.009029 | 6.41× | bit-exact | and all other workloads are measured in seconds, not all bit-exact, but with acceptable tolerance.
Maybe you can ask Claude the main reason why the new version is faster.
Why the Julia version is so faster than the C++ version?
It isn’t really Julia being faster than C++ as a language. The speed comes from how the data is accessed, which the C++ code does very expensively. The port went faster in two steps:
| Version | default (100 years) |
|---|---|
| C++ | 32m40s |
| First Julia version: line-by-line translation | 16m33s |
| Final Julia version: after profiling and caching | 5m12s |
1. Data look-ups. Every gpd/gfd call in C++ builds a key string like "pl#11001#hardWRoundW#" and searches a std::map, a tree compared string by string. Most product queries are also prefix scans. These calls sit inside the pixel × forest type × diameter class × product loops, so there are millions per year.
- First Julia version: it already used hash tables for exact keys and cached the prefix-scan results.
- Final version: it caches by key components, so no string is built at all. It also computes regional values once per region rather than once per pixel; they can’t change inside those loops.
It has to be said that using hash tables in Julia is much easier than in C++, at least at the time I started coding it, so this is another dimension that make it easier to “optimize” in julia…
is likely your performance killer, since it traverses a tree (not done by Julia’s Dict).
What do you mean? You’re using Julia’s standard Dict? It’s not equivalent to std::map (using Red-black tree usually, i.e. is sorted), but to std::unordered_map.
At least conceptually. Not even std::flat_map (introduced in C++23) may be best for you. C++ has been prevented from best map implementations… at least in older versions, why there are lots of alternatives.
I would have though Google’s Abseil absl::flat_hash_map might be better or best though AI also suggested something I hadn’t heard of:
Since you’re doing something with prefixes, maybe use a trie (though I’m not convinced, since tree-based, it also depends all all the operations you do):
This has nothing to do with Julia or C++, c’mon.
julia and c++ can go as low as you want, julia is limited by what llvm can express but most of the time thats far enough, now i don’t know how hard it is to get to get the best of the language.
So I guess if you want a comparison you get 4 level
- I dont care about perfs : julia wins
- I care about perf (out of gc) but I want readable code : julia wins
- I much care about perf : julia = c++
- Im completly crazy and I want assymbly instruction that llvm can never prove right : c++ wins
Indeed, I did ask (another) Ai:
How reliable is ai port of a simulation model from c++ to Julia?
And part of the answer was:
The “Accidental Optimization” Phenomenon: Interestingly, because Julia makes features like dictionaries, hashes, and high-level abstractions much easier to write and optimize than C++, an AI-ported Julia model can sometimes outperform the original C++ code. This usually happens not because Julia is inherently “faster than C++,” but because the AI cleans up convoluted, legacy C++ memory or data-access bottlenecks during the port.
And that is indeed very much this case. Just didn’t expect this to be so important.
If a typical codepath in a 12 year old codebase becomes more than 6 times faster by just changing a map to an unsorted map, and by not repeatedly constructing and tearing down strings inside a hot loop, this is just code that nobody sought to optimize. Especially when it comes to controlling memory layout I’d say a systems language does way better than Julia. The fact that your LLM happened to optimize that part of the code has nothing to do with either language. Extrapolating from all of this to the OP claim is clickbait, IMO.
No, it’s way more complicated than that.
There’s a lot of code out there that no one has micro-optimized, but which benefits greatly from a will designed stdlib. The purpose of a standard library is to provide good out of the box performance so that reasonably written code performs reasonably well.
It’s about 12k LOC (comments, libraries code and doc removed)
I am using Claude Opus 5.5, don’t know how to measure the cost/tokens usage of a particular task. I am using the “pro” account provided by my university, not API key.
To respond to other comments, I am not selling anything here, nor looking for clicks, just reported my experience as someone working on scientific simulations from a thematic domain. You need a spatial model, you see Python is too slow, you learn and implement your model in C++, and see it works “sufficiently fast” and you are happy.
I wasn’t able to squeeze C++ performance the way it could have been possible. I am sure the LLM could do it, but I am not sure I could then read the code. My claim is that doing that in Julia (by myself or by the LLM) is much easier while keeping the code high-level, compact, and readable by a non-expert. At least, this has been my experience.
Sure, but that’s a different discussion.