Will programmers write more efficient code during the memory shortage?

Will programmers write more efficient code during the memory shortage?

148 pointsby amichail239 comments

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • > Will programmers write more efficient code during the memory shortage?

    If we can insert "some" then Yes.

    > use of more advanced algorithms and data structures that use less memory?

    I don't think so.

    At least at work there is a push to decrease memory usage but the way I've seen it playing out is not using some O(N) data structure instead of O(N lg(N)) per-say but instead replacing `int[]` with `byte[]` or in-lining some fields to remove some indirection costs.

  • I'll just recognise that I'm old (and a bit grumpy): back in the day, if you didn't write minimally efficient code, it simply wouldn't run or it would be terribly slow.

    Young devs have not been exposed to this and they can get away with writing inefficient code most of the time, sometimes all of the time.

    And even if there is a RAM shortage, we are still in the Gigabyte age. So I don't think we will go back to cycle and byte counting.

    I can't even get some devs to care if their query runs in 3s or 8ms.

  • "will they" seems like the least interesting/useful question though. How can we, e.g. raise awareness in users and programmers that this is possible and useful?

    I wanna hang out with coders who care, I wanna read articles about caring and how you can achieve more with less code, and I want to see video content that visualizes the sheer insanity of it all. Like those "scale of the universe" videos, except the complexity isn't fascinating, but embarrassing.

    Make it uncool, make software bloat a goober thing you people do at most because they "have to", for pointy-haired bosses, or because they're in a rush or under other constraints. Not something that just gets normalized because hey, thinking is hard, caring is hard, so let's all conspire and pretend we're not being deplorable slobs, under the "leadership" of even worse slobs. There is little technical difficulty here, it's mostly social. Ignorance and greed are in cahoots and don't want to get called out, so call them out.

    Though I think to start with, you have to not give a shit about the majority, and huddle with people who care and make better things. If the majority comes around, great, if not, still better than standing on the beach, wondering if the ocean will ever spontaneously take this or that shape.

  • > I wanna hang out with coders who care, I wanna read articles about caring and how you can achieve more with less code

    This very much reminds me of an expression coined by Loris Cro (VP of Community at Zig Foundation): "Create software you can love".

    Looks like it's even got a website these days: https://softwareyoucan.love/

  • No.

    Even today it is possible to use languages and programming techniques to be ultra efficient when it comes to memory. It's not that difficult to use them but the world don't care.

    Actual example: I have built same utility using Rust, Zig and Haskell (and Go, humorous writeup[0]). Rust binary is 450kb, Haskell binary 30mb. Zig was unfinished but I constrained memory to 512kb just for fun.

    Thus it's not about memory per se but more about convenience. Many applications could be scaled by 1-3 degrees of magnitude in memory if they reused techniques but... no one cares.

    4K resolution frame is ~40mb uncompressed. Another 10mb is 80k lines of text. Thus fitting in 50mb for 99.8% of applications should be perfectly doable with today's tech.

    If the price increase would be per each next 1mb then maaaaaybeeee. But if it's like 100% over GB then I'm sure it won't have any impact.

    [0]: https://xlii.space/eng/the-four-language-waltz-a-tale-of-all...

    by xlii
  • You can drain all the system RAM with a tiny binary, so I am not sure you used the right metric.
  • Until prices hit the large hyperscalers, I don't think most people are going to make significant changes. You might see a small set of open source projects related to self hosting put in an effort, but in general, I don't think so.

    Some big-tech orgs (that have their own hardware) will take costs into account, but they already do that. The "optimization" is more likely to be business-optimizations; "this can be slower if it uses less memory", rather than inventing new stuff.

    Note that I am excluding any of the big AI labs. They are definitely going to be working to figure out how to use less memory, but that's primarily not related to the direct cost.

  • The new generation of Graviton on AWS ships with half the RAM per core in the standard family.
  • For the people I work with, I'd say no to writing more efficient code, and maybe to using more advanced algorithms. I say maybe only because they'll just ask an LLM to make it more memory efficient. Which in theory will cause the LLM to choose a more advanced DS. But I don't have a lot of faith that the LLM will get said DS right all the time.

    I work with dynamic language developers. Perl, React, Python and so on. Most currently don't care about memory usage. Some devs are actively wasteful. Usually in the name of code clarity or speed of delivery.

  • I don't think we will in the HN snark sense of "this react site or electron app uses way too much memory". Those companies will continue to work in the same way, maybe even less efficiently as people chase modern UIs with extra animations or videos or effects, or with some AI code generation tacking on too many features or tech debt.

    In specific sectors I do think we will see more optimization. If you're working on cloud compute or AI training / large scale data processing, there will be a big focus on optimization as prices are very large at that scale and shortages have a bigger effect.

    Also in gaming I think the next cycle will be different. Big game studios used to push for the best possible graphics that might require the newest consoles or high end gaming computers, but the next releases might not be as much of an upgrade. The next gen of consoles or graphics cards themselves might be delayed, or be less powerful, or be too expensive and flop, as chip manufacturing companies continue focus on more lucrative markets and leave average consumers behind.

    by naet
  • If that happens, we will see it in triple-A games first. If some new titles have significant lower hardware specs than expected.

    If buyers can't afford the hardware anymore, the studios need to adjust. It's definitively possible to scale games down a lot. There are a few AAA games that were "dumbed down" for the Switch 1 (Hogwarts, cyberpunk, ...). And that's a really low-spec device.

    There are two factors: existing gamers not able to afford upgrading. But also new gamers, that might only be able to afford much lower spec PCs than people who bought 2 years earlier.

    Why games? Because there is a clear point where people stop buying games. Minimum hw specs are known before buying.

  • That's memory efficient assets, not memory efficient code. The latter is already optimized for the former.
  • > There are two factors: existing gamers not able to afford upgrading. But also new gamers, that might only be able to afford much lower spec PCs than people who bought 2 years earlier.

    Spot on.

    Now with LLMs and desktop app libraries such as Tauri, there is little excuse in choosing Electron to build memory hungry apps other than laziness.

    by rvz
  • Games are designed for consoles which aren't going to change in the near term.
    by wmf
  • If you listen to gaming Youtube then the gaming industry is already in trouble from hardware costs and availability. I'm not sure if they are making a mountain out of a mole hill or not though.
  • I hope we continue local gaming, but my gut tells me we are going to see the opposite. I'd be willing to place a big bet on the new XBox leaning heavily into streaming, like GeForce now. Studios still get to build big, and the consoles get to rent hardware to you now, basically a wet dream for them.

    hardware costs must come down or every consumer segment is going to be renting, not owning, everything.

  • Are programmers and their use of data structures driving up storage requirements in games though? Or is it just high poly models and high res textures?
  • No reason to see it in AAA games. They already have to run on Series S, which has ~8 GB usable memory. Consoles are the primary target for any game (if they are not, it is not AAA). So minimum specs remain relatively static through a generation.
  • > If that happens, we will see it in triple-A games first. If some new titles have significant lower hardware specs than expected.

    Recently I booted up Insurgency: Sandstorm. With a 5800X and an Intel Arc B580 at 1080p and high graphics, the game runs at around 200 FPS. Meanwhile, pretty much any modern UE5 title (with the exception of Ready or Not and Split Fiction, from what I've seen) runs horribly - the interesting thing is that no matter how much you tweak the .ini files or change the graphics settings you can't get something like STALKER 2 or The Forever Winter or Borderlands 4 to run as well as UE4 with the graphics similar to those old games. Instead you get something that runs at like 10% of the render resolution and still doesn't get 60 FPS (I'm not exaggerating, literally the performance I got in The Forever Winter).

    There's no good technical reason for things to be that way (Unity still exists, and the games made in it struggle less) other than the devs or the higher ups choosing higher fidelity but more expensive rendering technologies and using upscaling and framegen not as something that helps laptops or when you need the spare GPU capacity (e.g. encoding a video recording of the game), but rather as something that's supposed to be used to even get to 60 FPS in the first place.

    I don't know what needs to change for things to get better.

    I also don't see anyone particularly caring about regular software, Electron et al are just too convenient to develop in (having to create per-platform UIs sucks in already-overworked teams).

  • It's definitely possible, but I agree with many other commenters it probably will not happen.

    I wrote an encrypted mesh networking library that runs on normal operating systems. A customer asked me if I could make it run on an ESP32 with 520 kiB of RAM. At first this seemed impossible, but it turned out that it was, and not even that hard. While the original library was not memory hungry at all for a desktop CPU, it still wasted space on unnecessarily large buffers. Cutting those out made the library run on an ESP32 while leaving plenty of room for an application.

    Also, my first PC was a 200 MHz single-core 32-bit AMD k6 with 32 MiB of RAM. This ran a graphical OS with browsers, word processors, 3D games and so on. Nowadays you can get a CPU with more than that amount of RAM as just built-in cache.

    So a good place to start optimizing code would be to actually get a "severely resource constrained" computer and start making your code work on it.

  • Programmers will write more efficient algorithms if their employers tell them to trade time-to-market for hardware cost. Previously, it was trade hardware cost for time-to-market.

    "Programmers" don't make this decision, the product owner does.

  • > trade time-to-market for hardware cost

    Enh. I think this only exists for some programmers, who can't write good code fast.

  • I disagree. Engineers choose the technical stack based on the specs.

    With LLMs, it's faster to ship even in a more verbose language like Go or Rust.

  • The classic excuse for industry-wide incompetence. The average programmer today can't write good code even if told it's an explicit priority.

    The manager wants the Submit button to submit the form, they rarely care how the programmer does it. It's the programmer that chose to install the 11,000 node_modules, to use React with 3 layers of state management on top with hybrid SSR/CSR and to do Kubernetes because that's what was on Hacker News that day or whatever. And guess what, somehow the Submit button does still not submit the form 10% of the time.

    Get rid of the junk and the program will be more efficient AND you'll ship quicker.

  • I don't believe so do for two reasons:

    - everyone assumes their program / website is the only thing running at the machine at a given time, and dev machines are always more powerful than user machines

    - it's not really lack of advanced data structures and algorithms that result in the bloat most of the time but the fact that programs and websites are delivered by large teams, there are dozens of submodules that are often loaded even when not needed, and doing it properly is hard to architect to without getting into big complexity and gnarly bugs waiting to happen when someone from other team modifies something and does not know full picture. So it's cheaper to just keep things the way they are to reduce complexity of architecture and fragility.

  • I'd say there's one more factor here, and it's probably the biggest one for websites and web apps.

    Advertisements and tracking.

    About 90% of the bloat found on most big company websites comes from these scripts being added all over the place. Ideally removing these would make these sites far more efficient, but the marketing and sales folks probably wouldn't allow it.

    by CM30
  • > the fact that programs and websites are delivered by large teams, there are dozens of submodules that are often loaded even when not needed

    Precisely this. We had an incident once where a CSV had a postal code field be interpreted as an integer by pandas, which of course results in stripping any leading 0s. After looking at what the code needed to do, I asked why they were using pandas in the first place, as it was literally just “read the CSV as-is into a list.” Guess what Python’s stdlib csv module doesn't do? Type inference.

    Instead of replacing the unnecessary pandas import (which brings along a fairly heavy transitive chain) with stdlib, they added additional code and tests to ensure this wouldn’t happen going forward.

    Some devs learn by trying. Others learn by reading docs. Most seem to learn by reading blog posts that use unnecessary 3rd party packages.

  • It's a bit more subtle than bad assumptions.

    The main place RAM usage is going to get optimized is on the server side, because the client's RAM is a tragedy of the commons. If you're reducing RAM usage while your competitor adds features then the extra RAM saved by your app will just be silently allocated to theirs, the device won't feel any different and the user will prefer your competitor. There is little incentive to optimize RAM usage on the client side because it only helps other companies, so nobody does it - except (ironically) browser devs, who tend to assume they have first dibs on all the RAM of the device.

    If you really wanted people to care about it OS devs would need to surface memory usage of apps visibly in a way ordinary users can understand and translate to customer feedback forms, which is difficult.

  • Some programmers will write more efficient code. At my $dayjob (one of the big tech companies) we're already planning a major goal next year of optimizing server code to reduce RAM requirements, and this is directly in response to the crunch.

    In practice I expect most optimizations will come from "stop doing stupid stuff" and not "use fancy advanced algorithms." But that's a cynical perspective so don't be cynical like me.

  • even a lot of the fancy algorithms are ways to not do something you dont need to do, it's rooting out waste all the way down.