Live data from Hacker News

There's no reason for software to be slow anymore

danluu.com

211–220 of 530 posts

Re: There's no reason for software to be slow anymore

#211
post #210

LLMs have essentially made any language above the C++/Rust systems level tier obsolete. The only reason you picked a language like C# or Python is often out of convenience of having a broad ecosystem or due to the lower level languages being too hard to master, with too many footguns. The tradeoff being is that you got a less performant implement, while being easier to write. Nowadays, those arguments are dead. LLMs…

Yeah, let LLM write C++ when your team have cannot comfortably write C++ in the first place. This is surely a frankly safter way than human-written C# and Python.

Re: There's no reason for software to be slow anymore

#212
post #146

Next time you ask your AI of choice to build an app, please tell them to use plain language without frameworks at all and keep modules to a minimum (ie. node express, ejs and pg, nothing else) and you will see a huuuuge difference

I had the same thought a few days ago. Coding agents have rendered frameworks obsolete. Apparently many people disagree though.

I like to use frameworks to steer the agent. I constrain it different primitives for different tasks in order get the shape I want without explicitly prompting too much. You can think of it as API driven development

Re: There's no reason for software to be slow anymore

#213

> performance work that used to require a person or team that had a rare set of skills can be done by anyone who can type a few sentences This idea is the reason why software will keep getting slower and less reliable. Because it's wrong and yet people believe it. Not only do people believe this, even if they didn't, they would still have the problem that most people (including many engineers) are bad at telling who…

> This idea is the reason why software will keep getting slower and less reliable. Because it's wrong and yet people believe it.

Not even close to being true. Prior to the advent of LLMs writing good SIMD was hard. Writing good SIMD for arbitrary tasks was _extra_ hard. Having the entire application be written with SIMD in mind was nigh impossible, from simple string parsing to data pipelining. Having arbitrary OpenCL/CUDA offloading to GPUs was a monstrous task. And even the people who were experts in these domains didn't have the time to do it in an afternoon.

But now you can. You can literally instruct your agent to write SIMD accelerated code everywhere, or to optimize down to it. And it just _does_.

> The essence of the problem is that the LLM does exactly what you tell it.

This is correct. I implore people to try writing a SaaS with an LLM, but instead of going the classic agentic project style of "design me an app", tell it to use C++ or Rust, use extensive SIMD intrinsics and inline assembly wherever possible. Just off those two instructions the difference in code quality is staggering.

Re: There's no reason for software to be slow anymore

#214

Yes, simply stop using JavaScript and give me static webpages. Done. I don't give a fuck if your website have a nice effect that follows my cursor, I just think about the amount of energy, effort and time wasted on making this demo. See https://deepseek.com/harness/en/ Is anyone really impressed by this gimmick anymore? Just give me a blank HTML with . Its fine. I dont think anyone care.

Sites can be fast with PHP and JavaScript. The slowness you see is mostly coming from all the frameworks too many developers "include" willy nilly with code that can only be described as bloat because 99% of it is completely unused, yet being loaded and computed by the browser on every load. That's what you're experiencing on too many websites.

Funnily enough, since most JS frameworks are utter junk, developers are better off instructing LLMs to write pure JS instead.

Fun story, I was writing some 3D graphics animations for a website, and the only dependency I allowed was three.js. It ran well, but the site was loading slightly too slow so I told the LLM to optimize. It essentially hit a hard wall and told me something along the lines of "I can't optimize further, three.js is the bottleneck due to blablabla, but you don't need it. If you want I can rewrite it with pure WebGL". I said sure and load times were cut by like 90% and framerate went up too. Staggering.

Re: There's no reason for software to be slow anymore

#215

Earlier quoted context omitted.

If we stored the edges (links) and nodes (pages) separately, rather than requiring you to blindly run a node's code just to discover what its edges might be, then you could skip the prediction and instead pre-cache the next hop for all edges just in case you follow one. You could even do this to two or three hops. This might seem wasteful, but if the web were content addressed instead of server addressed you could th…

>but if the web were content addressed instead of server addressed you could then be serving that cache to your municipality even after it became disconnected from the rest of the internet. This is already possible without content addressing with CDNs. They can serve content from a local cache even when the host is disconnected from the internet.

And the first thing webdevs did once this became widely available, is change their apps to cache-bust their code; between that, and the short release periods in webshit ecosystem in general, and security and privacy considerations messing up things as usual, the promise of users mostly hitting just local cache with any marginal request, never materialized.

Re: There's no reason for software to be slow anymore

#216
post #53

Earlier quoted context omitted.

It's not very hard to engineer software with these two constraints at the same time: * Must feel very responsive * Network requests can take up to 500ms end to end

That's why phones and windows use animations. You can also use intersitials related to the product you sell. Users are usually fine seeing many changes on the screen quickly because it gives the impression that stuff is happening on the background. For example in the interstitial, use an animation that takes up a small portion of the screen and not just a simple spinner or loading icon. Something more complicated wit…

> Users are usually fine seeing many changes on the screen quickly because it gives the impression that stuff is happening on the background

This gave me a chuckle because I personally hate things like watching the browser jump through 50+ redirects when logging into a website.

Re: There's no reason for software to be slow anymore

#217

Earlier quoted context omitted.

In my experience the main driver of latency is not ping time, but how long the server takes to process the request.

I think a lot of the time when people say the network is slow. They really mean their backend is slow. With a fast backend ~1-5ms response times (not even that fast). Streaming compression over something like SSE to keep your response sub 1kb packet (roughly an ethernet MTU). With a push based model, pushing data to a user is half their RTT latency. They will only experience their full RTT on actions they trigger. No…

1-5ms response time is clearly hard for most real world endpoints.

Re: There's no reason for software to be slow anymore

#218

"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 a…

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.

Re: There's no reason for software to be slow anymore

#219
post #29

Earlier quoted context omitted.

It's all about the test suite. The test suite becomes an executable specification, and the better the spec, the better the results you can get from AI.

How do you write a spec for correctness? Only the small and unimpressive programs can be checked exhaustively.

You can formally prove the correctness of even massive programs.

Re: There's no reason for software to be slow anymore

#220
post #146

Next time you ask your AI of choice to build an app, please tell them to use plain language without frameworks at all and keep modules to a minimum (ie. node express, ejs and pg, nothing else) and you will see a huuuuge difference

I had the same thought a few days ago. Coding agents have rendered frameworks obsolete. Apparently many people disagree though.

If this is true, the frameworks will either move to the specs or, worse, remain in the models.

You can't exhaustively write down all the possible ways for software to execute, especially since many programs run forever (e.g. servers, GUIs etc)

So when you say in your spec "when the user clicks here it shows this stuff" there is the tacit expectation that this will always happen and isn't dependent on the entire execution path up to this point. You also wouldn't expect a server to just finish execution after processing a request because you forgot to write "finally, cede control back to the main loop" at the end.

These assumptions are the framework. Almost everything you read is likely written in a framework, unless you limit yourself to non-technical writing for younger readers.

You could try to formalise the framework in your specs. But you'll then end up copy and pasting these paragraphs every time you want another server program. These context frameworks will probably get names, just like today.

Or you could skip that entirely and pretend you're not using a framework, but you are. It's just that the most has already learned tons of frameworks. What worries me here is stagnation. There's no way for the model to learn new frameworks. But this might be a short term effect. Maybe software in the next few years will look quite odd to those in the future as we keep writing it in the language of frameworks we already know. Maybe they'll look back at these relics and ask "what is a view, and why did the model understand that?"

Post reply on HN