Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There's no reason for software to be slow anymore

danluu.com

Post reply on HN
Print view View original

321–330 of 530 posts

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

#321

Post by [deleted] »

malisper wrote: post #209
hunterpayne wrote: post #197

"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

[deleted]

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

#323

Post by eviks »

Nevermark wrote: post #228
arjie wrote: post #221

I understand now that most software is slow because of co-tenancy reasons requiring controlling resources or simply because they're safely insulated from competition. e.g. GitHub is the former: you can give yourself a git host and CI/CD system that is much higher quality by yourself since you're probably not using its social features. I think things like Apple's five-finger inward gesture are the latter. Once you cou…

> Apple's five-finger inward gesture are the opposite. Once you could do it and start typing but nowadays it needs to render the animation There is no technical reason that animation should take that long. Someone said, "good enough" and let it be visibly slow. The reasons for that could be anything, including non-performant code in dependencies, written by other people. But it just does not take much computing power…

> There is no technical reason that animation should take that long.

The technical reason is you will not see all the animated beauty if it's fast, so animation forces feeds min delays for states transition

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

#324

Post by gritzko »

josephg wrote: post #307
gritzko wrote: post #272

Earlier quoted context omitted.

Hi Joseph, A story for a story. I had my CRDT implementation in libdog, which does per-token CRDT weave/diff/merge over a DAG of git blobs. It was written by Claude 4.8 I believe, in several iterations. It was, as you may guess, a piece of neuro-slop that passed the tests by some miracle. Once I had some time to look into it, I used a trick: I supplied it with my article on Chronofolds and some helpful kicks in the b…

> It has no sense of direction of its own maybe. Once you know what you are doing, you can ride it fine. If not, it makes a misstep so later things go haywire, and you are left guessing why. This is a perfect description. Last week I asked claude opus to get AAC audio working in davinci resolve on linux. It managed to add aac in mov and mp4 containers very quickly. But mkv was another matter. For mkv files, resolve d…

Like Aladdin's jinni is a slave of the lamp, LLM is a slave of its context window :)

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

#325

Post by MaxL93 »

bdhdhduuyd wrote: post #264

For me the comparison has always been 3DsMax vs Blender. Same kind of software, same kind of features, but Blender is so much faster. Architectural decisions have always been important.

You could compare it to Windows vs. Linux in a sense. 3ds Max has decades of legacy plugin/SDK compatibility baggage, lots of commercial and contractual obligations with business/enterprise customers... and Blender has none of those things weighing it down.

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

#327

Post by nottorp »

bensyverson wrote: post #92

Much like security, optimization is now a function of token spend—which in some ways means it's a function of care. The reason why software may continue to be slower or less secure than it could be is simply that no one cares enough to invest the time and money in improving it. Off-topic, but Dan, in the name of all that is holy, throw a `max-width: 40em;` on your blog!

If i had to complain about something, it's the font that's too small.

I paid for a wide screen monitor, let me use the whole width of the screen.

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

#328

Post by embedding-shape »

te_chris wrote: post #260
eaftan wrote: post #148

I'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, 100%. I’ve rewritten some hydrology code in rust using codex sol to first a) profile and create comprehensive tests of the python, b) create full benchmark suites, c) create full scientific benchmark suites, then d) port to rust using a few different techniques. It works, it’s at least 5x faster, sometimes much more, and memory use is like 10x less and even less in cases where lots of map tiles are involved. Th…

> What I’m wondering now is can we reliably evolve python and have codex act as an extremely unreliable transpiler to the rust.

Why you even start with Python at this point? Just write the Rust version straight up instead of porting things?

Personally I used to use dynamic languages for most things, because development and maintenance is so much faster and easier, particularly for larger projects (granted you know how to work with those sort of languages), but now when the LLM writes most of the code, I'm able to work as fast with Rust as with I used to be able to do with Clojure or other dynamic languages.

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

#329

Post by graemep »

ehnto wrote: post #44

One 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…

This is true, but it is an entirely different problem in a different place to what the article is talking about.

The optimisations the article is talking about would help even with this problem if backends responded faster - although not as much as actually avoiding unnecessary network requests in the first place, of course.

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

#330

Post by mawadev »

Lucasoato wrote: post #311
mawadev wrote: post #289

Earlier quoted context omitted.

I agree and see this as a side effect of a subtler thing. As people shall be replacable, software is designed and subtly mimics the organization's communication patterns. Features are cut up into the tiniest pieces with clear separation from the start (at least its claimed), and over time whatever change or feature seems overly complicated, won't be done or won't be done in a sane manner because its uneconomical. You…

> ticket driven development I feel this is so much real. Like if there were two kinds of companies: the ones who deliver, they care about their product but most of all they care about their customers, the managers get their hands dirty and everyone pushes towards the same direction; then there are companies in which you open a ticket and wait for two weeks for something that should take 5 minutes, customers and produ…

I could go on about this all day. Best meme is when you estimate stories for storypoints and then they haggle with you without changing the content of the story. Meanwhile points mean actual time. Then on another side if you haggled down points, you then have more slots for more points. So you end up getting assigned 3x work for the same time. The blame game starts when the sprints elapse lmao
Post reply on HN