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

The world could run on older hardware if software optimization was a priority

twitter.com

Post reply on HN
Print view View original

201–210 of 842 posts

Re: The world could run on older hardware if software optimization was a priority

#201

Post by Zak »

sgarland wrote: post #164
Zak wrote: post #95

Earlier quoted context omitted.

The backend programming language usually isn't a significant bottleneck; running dozens of database queries in sequence is the usual bottleneck, often compounded by inefficient queries, inappropriate indexing, and the like.

Yep. I’m a DBRE, and can confirm, it’s almost always the DB, with the explicit caveat that it’s also rarely the fault of the DB itself, but rather the fault of poor schema and query design. Queries I can sometimes rewrite, and there’s nothing more satisfying than handing a team a 99% speed-up with a couple of lines of SQL. Sometimes I can’t, and it’s both painful and frustrating to explain that the reason the dead-si…

It seems to me most developers don't want to learn much about the database and would prefer to hide it behind the abstractions used by their language of choice. I can relate to a degree; I was particularly put off by SQL's syntax (and still dislike it), but eventually came to see the value of leaning into the database's capabilities.

Re: The world could run on older hardware if software optimization was a priority

#202

Post by sabellito »

alkonaut wrote: post #181

"The world" runs on _features_ not elegant, fast, or bug free software. To the end user, there is no difference between a lack of a feature, and a bug. Nor is there any meaningful difference between software taking 5 minutes to complete something because of poor performance, compared to the feature not being there and the user having to spend 5 minutes completing the same task manually. It's "slow". If you keep maxim…

Perfectly put. People who try to argue that more time should be spent on making software perform better probably aren't thinking about who's going to pay for that.

For the home/office computer, the money spent on more RAM and a better CPU enables all software it runs to be shipped more cheaply and with more features.

Re: The world could run on older hardware if software optimization was a priority

#203

Post by [deleted] »

cosmic_cheese wrote: post #151
esperent wrote: post #40

Earlier quoted context omitted.

> It's basically stealing This feels like hyperbole to me. Who is being stolen from here? Not the end user, they're getting the tradeoff of more features for a low price in exchange for less optimized software.

It’s only a tradeoff for the user if the user find the added features useful. Increasingly, this is not the case. My favorite example here is the Adobe Creative Suite, which for many users useful new features became far and few between some time ~15 years ago. For those users, all they got was a rather absurd degree of added bloat and slowness for essentially the same thing they were using in 2010. These users would’…

[deleted]

Re: The world could run on older hardware if software optimization was a priority

#204

Post by queuebert »

bob1029 wrote: post #46

We've been able to run order matching engines for entire exchanges on a single thread for over a decade by this point. I think this specific class of computational power - strictly serialized transaction processing - has not grown at the same rate as other metrics would suggest. Adding 31 additional cores doesn't make the order matching engine go any faster (it could only go slower). If your product is handling fewer…

Why can you not match orders in parallel using logarithmic reduction, the same way you would sort in parallel? Is it that there is not enough other computation being done other than sorting by time and price?

Re: The world could run on older hardware if software optimization was a priority

#205

Post by agentultra »

bob1029 wrote: post #166
bluGill wrote: post #129

Earlier quoted context omitted.

You are only able to do that because you are doing simple processing on each transaction. If you had to do more complex processing on each transaction it wouldn't be possible to do that many. Though it is hard for me to imagine what more complex processing would be (I'm not in your domain)

The order matching engine is mostly about updating an in-memory order book representation. It is rarely the case that high volume transaction processing facilities also need to deal with deeply complex transactions. I can't think of many domains of business wherein each transaction is so compute intensive that waiting for I/O doesn't typically dominate.

I work in card payments transaction processing and IO dominates. You need to have big models and lots of data to authorize a transaction. And you need that data as fresh as possible and as close to your compute as possible... but you're always dominated by IO. Computing the authorization is super cheap.

Tends to scale vertically rather than horizontally. Give me massive caches and wide registers and I can keep them full. For now though a lot of stuff is run on commodity cloud hardware so... eh.

Re: The world could run on older hardware if software optimization was a priority

#206

Post by inetknght »

3036e4 wrote: post #191
inetknght wrote: post #103

Earlier quoted context omitted.

> It's basically stealing. This is exactly right. Why should the company pay an extra $250k in salary to "optimize" when they can just offload that salary to their customers' devices instead? The extra couple of seconds, extra megabytes of bandwidth, and shittery of the whole ecosystem has been externalized to customers in search of ill-gotten profits.

It's like ignoring backwards compatibility. That is really cheap since all the cost is pushed to end-users (that have to relearn the UI) or second/third-party developers (that have to rewrite their client code to work with a new API). But it's OK since everyone is doing it and also without all those pointless rewrites many of us would not have a job.

> without all those pointless rewrites many of us would not have a job.

I hear arguments like this fairly often. I don't believe it's true.

Instead of having a job writing a pointless rewrite, you might have a job optimizing software. You might have a different career altogether. Having a job won't go away: what you do for your job will simply change.

Re: The world could run on older hardware if software optimization was a priority

#208

Post by caseyy »

michaelgburton wrote: post #183
caseyy wrote: post #135

Earlier quoted context omitted.

We have much hardware on the secondary market (resale) that's only 2-3x slower than pristine new primary market devices. It is cheap, it is reuse, and it helps people save in a hyper-consumerist society. The common complaint is that it doesn't run bloated software anymore. And I don't think we can make non-bloated software for a variety of reasons. As a video game developer, I can add some perspective (N=1 if you wil…

One only needs to look at Horizon: Zero Dawn to note that the truth of this is deeply uneven across the games industry. World streaming architectures are incredible technical achievements. So are moddable engines. There are plenty of technical limits being pushed by devs, it's just not done at all levels.

You are right, but you picked a game by a studio known for its technical expertise, with plenty of points to prove about quality game development. I'd like them to be the future of this industry.

But right now, 8-9/10 game developers and publishers are deeply concerned with cash and rather unconcerned by technical excellence or games as a form of interactive art (where, once again, Guerrilla and many other Sony studios are).

Re: The world could run on older hardware if software optimization was a priority

#209

Post by queuebert »

bluGill wrote: post #188
bob1029 wrote: post #166

Earlier quoted context omitted.

The order matching engine is mostly about updating an in-memory order book representation. It is rarely the case that high volume transaction processing facilities also need to deal with deeply complex transactions. I can't think of many domains of business wherein each transaction is so compute intensive that waiting for I/O doesn't typically dominate.

HFT would love to do more complex calculations for some of their trades. They often make the compromise of using a faster algorithm that is known to be right only 60% of the time vs the better but slower algorithm that is right 90% of the time. That is a different problem from yours though and so it has different considerations. In some areas I/O dominates, in some it does not.

In a perfect world, maximizing (EV/op) x (ops/sec) should be done for even user software. How many person-years of productivity are lost each year to people waiting for Windows or Office to start up, finish updating, etc?

Re: The world could run on older hardware if software optimization was a priority

#210

Post by dgb23 »

mjr00 wrote: post #179
caseyy wrote: post #91

There is an argument to be made that the market buys bug-filled, inefficient software about as well as it buys pristine software. And one of them is the cheapest software you could make. It's similar to the "Market for Lemons" story. In short, the market sells as if all goods were high-quality but underhandedly reduces the quality to reduce marginal costs. The buyer cannot differentiate between high and low-quality g…

> the market sells as if all goods were high-quality The phrase "high-quality" is doing work here. The implication I'm reading is that poor performance = low quality. However, the applications people are mentioning in this comment section as low performance (Teams, Slack, Jira, etc) all have competitors with much better performance. But if I ask a person to pick between Slack and, say, a a fast IRC client like Weecha…

You are comparing applications with wildly different features and UI. That's neither an argument for nor against performance as an important quality metric.

How fast you can compile, start and execute some particular code matters. The experience of using a program that performs well if you use it daily matters.

Performance is not just a quantitative issue. It leaks into everything, from architecture to delivery to user experience. Bad performance has expensive secondary effects, because we introduce complexity to patch over it like horizontal scaling, caching or eventual consistency. It limits our ability to make things immediately responsive and reliable at the same time.

Post reply on HN