A RAM Edition of Dirty Coding Tricks • Hacker News Board

Re: A RAM Edition of Dirty Coding Tricks

#71

Post by leeter » Mon, Dec 18, 2017, 4:44 PM UTC

russellbeattie wrote: post #10

Whenever I think, "Thank goodness the limited memory days are behind us", it pops up again and again. Sure, you can buy a new iMac Pro with 128GB of RAM(!!) and smartphones regularly have 8GB available, but the increasingly popular IOT devices and smart consumer hardware (like streaming media boxes, etc.) try to limit the BOM cost and thus limit memory as much as possible. Tiny memory leaks become an issue, or random…

I still use things like struct packing on a regular basis to reduce bloat. Just because systems have absurd amounts of ram doesn't mean that Chrome won't gobble all of it. If I can get my application's memory down to just a few pages (4k chunks on x86) then I'm much easier to page in after they switch back from Chrome. I don't have hard targets but I do still make an effort here because it's worth it not to get bugs about my applications being slow because of other bad actors.

Re: A RAM Edition of Dirty Coding Tricks

#72

Post by ksk » Mon, Dec 18, 2017, 7:00 PM UTC

FRex wrote: post #61

golergka wrote: post #52

Earlier quoted context omitted.

That's a trade off. Have you ever estimated a game development budget? Sure, we can write our own engine in C++ and be running smoothly on 7-year old machines - which, theoretically, can bring some additional sales. But we can also use the money that C++ engine developers cost to hire much cheaper mid-level devs with a typical industry engine (Unity/Unreal), invest that time in additional polish/iterations and get a…

No. There is no trade off. This game is a VN, this is a very simple genre, I could reimplement the engine easily in C++ and Lua and I do not consider myself a superstar. And I do not need to be Gordon Ramsey to be able to tell I've been given a plate of shit. The C++ part is a complete strawman, nowhere did I say that everyone must now use C++ only. Unity, Unreal, Python, Electron, et al are not the problem here, the…

I think the problem is two fold. Its this ideal that you should be working on "hard problems". Which for developers, means working on things one step above their current competency. Well that is great if you're doing research, but if you're shipping something or doing anything on production, you want to hire someone for whom this problem is easy, not hard. You don't want the wild-eyed fresh graduate with 'crazy' ideas, you want the old grizzled veteran for whom this sort of stuff is old-hat and boring because they've done it a million times. The first solution you come up with to any problem is never going to be the best solution. Its only when you've solved the same problem a few times that you will get better at solving it.

The second problem that I see is that of 'free' speedups. If you get a free speedup from hardware tech (like SSDs), you're thought is never going to be how can I match this speedup with my own code optimization, it means your production time is now cut in half or you can go focus on other things. Its only when you're forced to come in under a certain performance budget that people bother to optimize. As it is, this only seems to happen in fixed-hardware situations like console games/embedded systems, etc.

Re: A RAM Edition of Dirty Coding Tricks

#73

Post by Paul-ish » Mon, Dec 18, 2017, 7:21 PM UTC

bastawhiz wrote: post #13

mattnewport wrote: post #11

A pretty common trick that was part of game programmer lore back in the PS2 / Xbox era was to have a large static array hidden away in some code file somewhere. When days before shipping you couldn't quite fit the release build in to memory this allowed a heroic programmer to miraculously 'find' a few hundred extra kilobytes of memory by reducing the size of the array by just enough to fit. There was a less common va…

Sadly this usually works only once, especially if it's one person doing it. I used to work on the performance team at a Bay Area company. One of the things we did to keep our JavaScript bundle sizes under control was introduce a "ratchet". There was a threshold, enforced by CI, that you couldn't let the bundle size exceed without getting in touch with us first and figuring something out. [0] This worked wonders for a…

> Engineers started working around the ratchet by hoarding dead code and disguising it to look "not dead" so that it could be easily removed later when a few dozen kilobytes were needed.

Sounds like an example of the cobra effect[1]

[1] https://en.wikipedia.org/wiki/Cobra_effect

Re: A RAM Edition of Dirty Coding Tricks

#74

Post by tekromancr » Mon, Dec 18, 2017, 7:22 PM UTC

FRex wrote: post #19

mattnewport wrote: post #11

A pretty common trick that was part of game programmer lore back in the PS2 / Xbox era was to have a large static array hidden away in some code file somewhere. When days before shipping you couldn't quite fit the release build in to memory this allowed a heroic programmer to miraculously 'find' a few hundred extra kilobytes of memory by reducing the size of the array by just enough to fit. There was a less common va…

I have seen it mentioned here on page 4: https://www.gamasutra.com/view/feature/132500/dirty_coding_t... There's yet another article on dirty game hacks that I recall due to EULA self-hack: https://www.gamasutra.com/view/feature/194772/dirty_game_dev... I have no idea why this article doesn't link to these two and just to the 2017 one because it's not like these are current generation tricks, it's just that Brandon S…

The one on the last page about using dexdrive was pretty cool. I used a similar technique to create ps1 save files that would trigger an exploit on the ps2 that would load unsigned code. I miss being able to do stuff like that. Modern systems are so locked down.

Re: A RAM Edition of Dirty Coding Tricks

#75

Post by hoosieree » Tue, Dec 19, 2017, 12:32 AM UTC

Bartweiss wrote: post #31

TeMPOraL wrote: post #14

Earlier quoted context omitted.

> Whenever I think, "Thank goodness the limited memory days are behind us", it pops up again and again. Sure, you can buy a new iMac Pro with 128GB of RAM(!!) and smartphones regularly have 8GB available I think you're underestimating the accretion of software bloat. You remember the days when you did exactly the same things , exactly as fast, with 1GB machines? 512MB machines? As long as devs don't give a fuck (er,…

I always think about Windows Vista when I hear "unlimited memory". Somebody looked at expanding memory and processing, and decided "let's have an animated 3D background for the OS, that'll be good". Memory is always going to be pushed to its limits unless devs and users alike go out of their way to keep it intact.

Sorry, I don't trust myself or you to exercise restraint. The ONLY thing that keeps memory usage in check is physics.

Re: A RAM Edition of Dirty Coding Tricks

#76

Post by Gaelan » Tue, Dec 19, 2017, 8:25 AM UTC

bigiain wrote: post #35

wging wrote: post #28

Earlier quoted context omitted.

You'll run into today's equivalent soon enough :)

Now I'm looking forward to the first website that decides it needs to restart Chrome between page changes for me...

As a web dev, I've often at least considered refreshing the page in an SPA due to some bug with client-side state—I guess that's the modern-day equivalent.