logoalt Hacker News

Writing Rust code that's fast by asking agents to make the code faster

64 pointsby mooredstoday at 3:38 PM27 commentsview on HN

Comments

metalspottoday at 4:32 PM

I have done a fair amount of low level performance optimization with Opus 5 and its reasoning is still very poor. Like why is CRC so slow and going through loops until I ask it if is using hardware instructions and it tells me it is using its own hand coded implementation poor. Reasoning about l1/l2/l3 cache hit ratios and their implications basically throwing darts at the wall, in the wrong room. If you give it a benchmark feedback loop then it might get there eventually but still massive alpha for low level systems engineers who instinctively know how this stuff works and can now automate 99% of the grind.

show 2 replies
lordnachotoday at 4:50 PM

I've been having great results with this kind of thing. I find that really just need a sensible framework within which the optimization can take place. Essentially just providing the measurement harness, and some sort of motivation for what I'm doing.

The great thing about LLM is that it seems to have the checklist for everything. If I rattle off a few things like "don't allocate on the hot path" and "remember to pin the cores" it will come up with a few items of its own that I might have forgotten.

Eventually, it will have gone through the whole list with me, while having documented all the measurements along the way.

But it's still guided by experience. If I see unusual numbers, I might say "hey did you forget to compile it in release mode?" and it will apologize and fix that. If I don't, it may just continue exploring without realising everything is wrong.

hombre_fataltoday at 4:26 PM

If it can be measured, then LLMs can optimize it.

Once I had repo commands that could dump `sample` results and a cpu profiler/trace and then a benchmark tool that let me A/A + ABBA/BAAB-test the current modified git workspace against HEAD or any commit, the LLMs could just do their thing.

And that's how my homemade terminal uses much less memory than ghostty/kitty/iterm yet has more throughput.

AI is going to increasingly unmask people and companies who don't care about correct and performant software now that it's become so trivial to guarantee both. It used to at least be expensive and time-consuming and expertise-demanding to do those things.

show 3 replies
ll1287today at 6:41 PM

AI is heaven for bullshitters, bloggers and (fake) benchmark addicts.

vatsachaktoday at 4:32 PM

I've found that this is a good way to introduce bespoke code into the codebase whose perf gains don't generalize.

Unless its an easy memory/parallel/algorithmic win, its not worth it.

show 1 reply
loegtoday at 4:34 PM

They're quite good at just iterating different "ideas" on a performance metric with an objective measure. They can use tools like `perf` and do some analysis on the output. Sometimes they go off in the weeds unproductively, and sometimes they give up because your goal was too high, but as long as you're sort of babysitting the process, you can make pretty rapid improvement to naive code.

show 1 reply
Keatstoday at 5:22 PM

As the author of Tera mentioned in the article, I am curious how it can get 2x faster. Was the benchmark using tera v2 with the `fast` feature enabled?

show 1 reply
pushpendrawtoday at 4:54 PM

one thing nobody mentioned here, once the agent is looping against the same benchmark it will happily optimize for the benchmark itself and not the real workload. worth rerunning the win against a slightly different input shape after, just to check it did not memorize the harness instead of actually fixing anything.

show 2 replies