4 ms·

"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 m

"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.

malisper 2mo ago
> This person doesn't understand how to make efficient code The author is one of the most knowledgeable people about performance there is
- geraneum 2mo ago
  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.
- hunterpayne 2mo ago
  The author didn't write the quote.
  - Kiro 2mo ago
    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.
    - rrook 2mo ago
      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.
- deleted 2mo ago
  [deleted]
whatisthiseven 2mo ago
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.
userbinator 2mo ago
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 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..."
ddejohn 2mo ago
The author was paraphrasing a tweet written by somebody else: > The other day, I saw a viral tweet saying [...]
momocowcow 2mo ago
I remember the co-founder of Anduril Industries being the author of this tweet!
99954bb63ccc 2mo ago
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.
iainmerrick 2mo ago
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.

malisper 2mo ago

> This person doesn't understand how to make efficient code The author is one of the most knowledgeable people about performance there is

geraneum 2mo ago
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.
hunterpayne 2mo ago
The author didn't write the quote.
- Kiro 2mo ago
  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.
  - rrook 2mo ago
    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.
deleted 2mo ago
[deleted]

whatisthiseven 2mo ago

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.

userbinator 2mo ago

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 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..."

ddejohn 2mo ago

The author was paraphrasing a tweet written by somebody else: > The other day, I saw a viral tweet saying [...]

momocowcow 2mo ago

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

99954bb63ccc 2mo ago

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.

iainmerrick 2mo ago

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.