Using a lot less RAM often implies using more CPU, so even with inflated RAM prices, it's not a good tradeoff (at least not in general).

▲

zozbot234 2 hours ago | parent | next [-]

In practice, you generally see the opposite. The "CPU" is in fact limited by memory throughput. (The exception is intense number crunching or similar compute-heavy code, where thermal and power limits come into play. But much of that code can be shifted to the GPU.)

▲

pron 2 hours ago | parent [-]

RAM throughput and RAM footprint are only weakly related. The throughput is governed by the cache locality of access patterns. A program with a 50MB footprint could put more pressure on the RAM bus than one with a 5GB footprint.

▲

zozbot234 2 hours ago | parent [-]

You're absolutely right? I don't really disagree with anything you're saying there, that's why I said "generally" and "in practice".

	▲	pron an hour ago \| parent [-]
		Reducing your RAM consumption is not the best approach to reducing your RAM throughput is my point. It could be effective in some specific situations, but I would definitely not say that those situations are more common than the other ones.

▲

zamadatix 2 hours ago | parent | prev | next [-]

The tradeoff has almost exclusively been development time vs resource efficiency. Very few devs are graced with enough time to optimize something to the point of dealing with theoretical tradeoff balances of near optimal implementations.

▲

pron an hour ago | parent [-]

That's fine, but I was responding to a comment that said that RAM prices would put pressure to optimise footprint. Optimising footprint could often lead to wasting more CPU, even if your starting point was optimising for neither.

	▲	zamadatix 15 minutes ago \| parent [-]
		My response was that I disagree with this conclusion, not that I'm changing the premise. If the starting point was optimising for neither it's VERY easy to optimize one without tanking the other, there's just no pressure to do so at the moment. What you're saying only makes sense if apps were RAM bloated because of algorithmic tradeoffs. If you look at bloated apps, it's because of selecting extremely high level abstractions which are quicker to develop with. E.g. the web based implementation of the Start Menu in Windows 11 is not faster just because it uses more RAM, but it is waaaay easier to develop for.

▲

DimmieMan 2 hours ago | parent | prev | next [-]

Only if the software is optimised for either in the first place.

Ton of software out there where optimisation of both memory and cpu has been pushed to the side because development hours is more costly than a bit of extra resource usage.

▲

dehrmann 2 hours ago | parent | prev | next [-]

You're thinking an algorithmic tradeoff, but this is an abstraction tradeoff.

	▲	pron an hour ago \| parent [-]
		Some of the algorithms are built deep into the runtime. E.g. languages that rely on malloc/free allocators (which require maintaining free lists) are making a pretty significnant tradoff of wasting CPU to save on RAM as opposed to languages using moving collectors.

▲

IsTom 2 hours ago | parent | prev [-]

Or just using less electron and writing less shit code.