171–180 of 264 posts
Earlier quoted context omitted.
The language doesn't matter much if you have memory-hungry workloads. Whether it's Rust or C or C#, you can write quite memory efficient code in either.
And Java? Language matters.
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…
> 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 interesti…
Studios need to start creating custom engines again, for one. We'll get better games with less unsatisfying jank, some of the projects will actually cost less (which is paradoxical to some) and performance is likely to jump significantly. Off-the-shelf engines have as many costs as they have benefits, but like a lot of technology people refuse to look at the choice as a trade-off, and to the extent that they acknowledge it's a trade-off the implicit admission is always that it's a trade-off that the user/player is paying the most for, so it's OK.
If companies start creating custom engines en masse again it will also help solve part of the competency crisis in the industry, because they'll be forced to actually learn and educate people on how things work.
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.
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.
stepping outside of garbage collection, and managed runtime systems could teach a lot; there was a book written 20 or so years ago;
Earlier quoted context omitted.
The key word here is “server”. Optimizing memory server-side directly translates to cost savings for companies. There is a lot less incentive to optimize memory for code that runs on the user’s computer.
There's plenty of incentive if it causes your users to churn.
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...
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.
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…
I suspect you're imagining something like, just write some vanilla JS and maybe some tasteful but not bloated CSS.
You could do that. Then I'll come along with my old man Win32 skills and write a form with a submit button that sends the data by doing a memcpy into a UDP packet. It will take 300 kilobytes of RAM and start in 0.1 seconds. That'll make it approx 100x more RAM efficient than the baseline you can manage with Chrome, where an empty renderer process takes 23 MB of RAM to achieve nothing and starts so slowly the browser has to cache them in the background.
On the other hand, delivering features your users expect might be a bit harder. Shipping and updating that app will be painful for me, unless I use [plug] https://hydraulic.dev/ to make it easy [/plug], and the styling options are limited to setting solid color backgrounds on things. Things the product manager views as basic, like adding a dark mode, will take a surprising amount of effort. The app is likely to be more crash prone than the web app due to all the manual memory management required. Text zoom won't work. I'll have to write in C or maybe C++ if I'm feeling extravagent.
So there's got to be a balance somewhere. Features do matter.
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 o…
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.