I've been using computers for 4 decades. They have gotten no faster. The nuclear plant computer system we built in 1989 had to present selected screens in 1 second. I don't think any apps I use today can do that.
[flagged]
There's no reason for software to be slow anymore
201–210 of 531 posts
Re: There's no reason for software to be slow anymore
#202One of the biggest causes of slowness is just waiting for web requests. The fact that so much software is either online or built using the same stack even if it isn't, puts all that software in this blocked/waiting state constantly while using it. Anyone not in the US feels this even more since so much online is US hosted, 300ms for every little interaction adds up quick. If your software has the affordance of a wait…
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.
Now the network to you is distance to the server (not your rail/nextjs backend taking 400ms). Things like 4G and 3G are fine. The real problem is when you have such bad signal you effectively have no down or up.
Re: There's no reason for software to be slow anymore
#203One article said secure software was here because of AI, this one says it can now be performant. Yet when I ask for code it writes, by default, both slow and insecure code that mostly works. Kinda. As I try to get AI to rewrite it into more secure, less bloated and optimized code is when it starts to randomly crash. Then I read articles about how AI is "moving too fast" and cry.
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.
It doesn't sound very intelligent to just brute force iterate until you pass all the tests. This sounds like what Rich Hickey called "bashing into the guard rails". Even if we assume the tests suite is perfect and will guide the model to a correct solution, maybe this is one case we really should just say "LLM" rather than "AI".
Re: There's no reason for software to be slow anymore
#204Here's this boiled down: > A stochastic search process with an executable optimization objective over space of programs S can only maintain or improve the objective This is superoptimization. We've known this since the 80s (Massalin, STOKE is more recent: https://github.com/StanfordPL/stoke ) The only novelty is that the proposer is now way better with LMs. Further, there's a large number of reasons for software writ…
> A stochastic search process with an executable optimization objective over space of programs S can only maintain or improve the objective Reasons this doesn't follow: (1) Benchmarks never match real world use, and many optimizations the improve benchmarks degrade cases that aren't measured (think about how CPU cache behavior can be surprising) (2) In software performance optimization, frequently there is significan…
Both of those things are indicators of deficiencies in the testing process.
Re: There's no reason for software to be slow anymore
#205Earlier quoted context omitted.
Skill issue. The fact is that with the right spec, agentic guardrails, and evals, frontier models can now one-shot secure, performant code. This is the job of software engineering now. Learn to properly use the tools for the job.
Very much not a skill issue; even with the best spec, guardrails and evals, frontier models will just do the hell they want. > one-shot secure, performant code. I call it reverse skill issue; it feels secure and performant because you can't verify properly, it feels right but it's actually broken in many nuanced ways. You can measure performance and produce a broken measurement as well. It's not as simple as you make…
[deleted]
Re: There's no reason for software to be slow anymore
#206Earlier quoted context omitted.
But it will definitely improve, either speed or volume.
I'm really bothered by the mindset of the people against this. People act like induced demand is evil. In reality, if more people were able to go wherever they wanted to go, that's actually a good thing regardless of if the existing people didn't get to go somewhere faster.
Most people use roads to get to work. It's definitely not where they want to go.
Re: There's no reason for software to be slow anymore
#207I've been working on a similar agentically engineered regex project called SafeRE: https://github.com/eaftan/safere https://eaftan.github.io/safere-intro/ Mine is for Java and is intended to be production grade. The first goal is to guarantee linear-time behavior to prevent ReDoS attacks. My collaborator and I have recently been optimizing it to try to surpass native RE2 in performance. It turns out optimizations are…
This sounds very interesting. Which JVM profiler do you use?
I've been using:
JMH as the framework to write microbenchmarks. It takes care of dealing with JIT warmup, etc. It's the standard way to write rigorous Java microbenchmarks.
async-profiler (https://github.com/async-profiler/async-profiler) for profiling. Java has a problem where many profilers are based on safepoints, which are biased toward particular program points. async-profiler is not biased in this way.
Java Flight Recorder for memory allocation data.
One thing I've observed in all of this is that it's really useful to have expertise in the programming language and ecosystem you're writing in, otherwise it's all Greek to you and you can't really guide the agent to do the right thing. I have opinions about e.g. profilers and I can point the agent to one that I think is more accurate than other options.
Re: There's no reason for software to be slow anymore
#208Earlier 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. Welcome to Next.js
Can next.js give me a page's links without requiring that I execute any code that I didn't have prior to visiting that page? The .js part makes me think not.
Speculative Rules API
{
"prefetch": [
{
"source": "list",
"urls": ["/checkout.html", "/thank-you.html"]
}
]
}
Re: There's no reason for software to be slow anymore
#209"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…
> This person doesn't understand how to make efficient code
The author is one of the most knowledgeable people about performance there is
Re: There's no reason for software to be slow anymore
#210LLMs 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 can now write perfect code in low-level languages, that is frankly _safer_ and _exponentially_ faster than implementations in high-level languages.