Hacker News Reader

Comment by hunterpayne | Hacker News Reader

"LLMs are causing slow, bloated, code are going to eat crow once they re-write everything in super-optimized assembly."

This person doesn't understand how to make efficient code. I can write code in almost any language (with a couple of exceptions) that outperforms "super-optimized assembly". Writing efficient code isn't about the language, and often isn't about the best algorithms either (but sometimes it is). Its about optimizing memory and cache use. And that's orthogonal to anything the author is writing about. Also, LLMs are terrible at optimizing memory utilization. There is just too little training code that does it well and far too much that doesn't.

As proof, I'm can literally feel the web getting slower and I bet many others feel this as well.

View on HN

My contradictory proof: I have been working on an old service with tons of performance issues, from server memory bloat, client graph rendering, excessive network requests, excessive repeat rendering, memory leaks, resource leaks, etc.

The app and service are measurably and subjectively faster. Because I chose to have the LLM focus on solving those problems. It obviously can. It described the issues in big-O.

It is a priority problem, as it always has been, not a knowledge or skill problem, like it always has been.

I think you’re talking somewhat at cross purposes to the original article.

The points I take away are:

- Good optimization is difficult and slow work, hence expensive, but LLMs can do it so we should be able to afford it more often now.

- There’s always a risk of over-fitting to your specific problem, but if everyone is now making bespoke optimizations maybe that isn’t actually a problem.

You said:

LLMs are terrible at optimizing memory utilization. There is just too little training code that does it well and far too much that doesn't.

There’s probably something in that, but it can be mitigated by testing against a local benchmark. LLMs are good at iterating tirelessly and finding incremental improvements. And as noted above, it doesn’t necessarily matter if your benchmark isn’t fully general.

> This person doesn't understand how to make efficient code

The author is one of the most knowledgeable people about performance there is

Seems like author’s main focus recently is AI and agents unsurprisingly, hence the suspicion. But it seems like he has a backgrounded in relevant fields in the past.

The author didn't write the quote.

Just admit that you were wrong instead of this doubling down nonsense. LLMs are amazing at optimizing memory utilization. They have no problem obsessing over fitting as much data as possible onto a single cache line and micro benchmarking cache hits.

This seems like way too caustic of a reaction, OP is correct.

If you actually know what you're doing in $language, and you know how $language wants to emit the assembly or whatever, there's no huge advantage to just programming directly in assembly.

I think it's more about not doing unnecessary things. Like a like a saying I heard somewhere "a clever person solves a problem, a wise person avoids it". Not every good idea _needs_ to become a feature. And if you think it's that good, give users the option to turn it on/off and track that as a metric.

The author was paraphrasing a tweet written by somebody else:

> The other day, I saw a viral tweet saying [...]

I remember the co-founder of Anduril Industries being the author of this tweet!

Also, LLMs are terrible at optimizing memory utilization.

I've already posted this elsewhere, but here it is again: https://news.ycombinator.com/item?id=49226923

A vibe-coded OS that runs on an 8088 with 256KB of RAM.

As proof, I'm can literally feel the web getting slower and I bet many others feel this as well.

"It's not the tool, it's how you use it..."

Reply on news.ycombinator.com