Makes me wonder why Rust isn't popular with game devs. Wouldn't Rust's borrow checker and resource management at compilation time make most of the described memory reclaiming issues obsolete?
> Makes me wonder why Rust isn't popular with game devs.
Too new to have a mature gamedev ecosystem. I only finally started tooling around with rust when someone tweeted they'd gotten it working on the PS4, but that still puts me in the early adopter boat.
> Wouldn't Rust's borrow checker and resource management at compilation time make most of the described memory reclaiming issues obsolete?
No. It might help you verify that the systems you're building to tackle these problems are correctly implemented, but it's not going to help you tackle the fundamental problem of e.g. "this game has more 'active' data than we actually have the RAM for".
In theory, this is the problem that virtual memory and page files solve. In practice, occasional small 50-100ms stalls which might be acceptable for a text editor are really nasty for a real time twitch and flow based game. 60fps gives you a frame budget of 16ms - if you want your animation to remain at a fluid 60fps, your absolute max frame time is 16ms.
So, games will end up writing their own memory management systems to e.g. partially load and unload textures at runtime. They'll build in knowledge of your level layout to try and prefetch textures before they're actually necessary based on where the player is moving, so they're available by the time the game needs them - and they might chose to render using a lower resolution version of a texture that was kept in memory if the high resolution version wasn't loaded in time instead of stalling the game.
Rust is definitely being looked at. The reason there are no big projects is that it’s still so new. For example the ability to write custom allocator is still going through the RFC process last I looked. Further it takes many man years of effort to write a AAA level game engine so there is quite a lot of inertia preventing moving to something new. We’re at the phase where people are experimenting within a relatively immature ecosystem. We’re probably a year or two away from a big project using Rust for part of their development process and at least four or five from a large project written from scratch. There are quite a few hobbiest and open source game projects though.
One reason is SIMD. Videogames contain quite a lot of math that benefit from SIMD a lot, be it MMX, SSE, AltiVec/VMX or NEON.
Another one is that borrow checker. Games are heavily multithreaded since X360. Game state + game assets = huge pile of data shared across threads. Borrow checker in Rust makes it harder to write parallel code that operates on that large shared state. For small state and/or plenty of RAM you can afford making copies but games can’t afford that. Sure Rust brings value here by eliminating a class of bugs, but for game clients (servers are different story) the optimal safety/resource tradeoff is at another place than e.g. for a web browser.
Finally, games often use many third-party libraries and frameworks (sometimes called middleware), and due to historic reasons majority of those are C or C++ libraries.
Rust has no issues sharing state across thread without jumping too much hoops, as long as you can make the borrow checker believe that only a single thread at a time gets to mutate state and when a piece of memory is accessible from multiple threads it's not mutable.
> and when a piece of memory is accessible from multiple threads it's not mutable.
In game engines, these pieces of memory often need to be mutable by multiple threads. E.g. see this old Intel article for a high-level overview how it might work:
https://software.intel.com/en-us/articles/designing-the-fram...
Now with DX12 / Vulkan it became even worse, because with them we no longer have _the_ render thread.
Sure, doing that the dangerous C++ way can introduce bugs. But the risks are different.
If you’re working on a web browser (that’s what Rust was created for), the worst thing that may happen, a compromised web site you’re viewing (maybe even by accidentally clicking a link) may infect your PC, steal all your data and turn your PC into a botnet node.
Most games can’t technically fail that bad, due to the following reasons (1) Most games don’t allow users to create content, only the developers do (2) Modern console games work in a hardware-assisted hypervisor (3) Some platforms even verify digital signatures of all the content they load.
I've only written a bit of Rust, but from what I've seen Rust makes the first 90% of optimizing for space-efficiency easy, but the next 90% (stuff like allocating from static buffers instead of on the heap, reusing/type-punning memory, tagged pointers, clever poking at the hardware/OS internals, etc) very difficult.
You can't do resource management at compile-time for games that have 50gb of assets. Also, Rust may help with accidental memory leaks, but you still have to deal with things like heap fragmentation.
Interesting point. Normally, your programming language can do little about fragmentation other than requesting a better allocator, if available (Windows?). Makes me think, maybe Rust's model would allow it to plan for better allocation requests? (Not saying Rust does that, just came as an idea.)
The main advantage I see Rust having here is making it a little easier to (ab)use the stack for temporary stuff in a way that can be verified to be safe. Nothing you can't already do in C++ at the expense of the occasional heisenbug.
Games often create their own allocators for a variety of reasons (specialized allocation strategies for speed or fragmentation reasons, adding debug statistics, enforcing memory budgets for (sub)systems, etc.) - although that's not terribly OS or language specific.
Game devs only change programming languages when console and OS vendors force them to do so.
That is how they moved from Assembly into C, C into C++, adopted Objective-C, adopted C# in their tools, accepted external middleware like Unreal or Unity.
So until one of the big desktop or console owners releases an SDK where Rust is the language, they will hardly adopt it.
Sure a few indies might do it, but it will be a blip on the radar of the usual Game Developer Conference attendees.
Rust's type system is intended to provide memory safety guarantees, which they define as explicitly not including memory leaks. You're not really any better off than just using C++ shared_ptr/unique_ptr.
Too new to have a mature gamedev ecosystem. I only finally started tooling around with rust when someone tweeted they'd gotten it working on the PS4, but that still puts me in the early adopter boat.
> Wouldn't Rust's borrow checker and resource management at compilation time make most of the described memory reclaiming issues obsolete?
No. It might help you verify that the systems you're building to tackle these problems are correctly implemented, but it's not going to help you tackle the fundamental problem of e.g. "this game has more 'active' data than we actually have the RAM for".
In theory, this is the problem that virtual memory and page files solve. In practice, occasional small 50-100ms stalls which might be acceptable for a text editor are really nasty for a real time twitch and flow based game. 60fps gives you a frame budget of 16ms - if you want your animation to remain at a fluid 60fps, your absolute max frame time is 16ms.
So, games will end up writing their own memory management systems to e.g. partially load and unload textures at runtime. They'll build in knowledge of your level layout to try and prefetch textures before they're actually necessary based on where the player is moving, so they're available by the time the game needs them - and they might chose to render using a lower resolution version of a texture that was kept in memory if the high resolution version wasn't loaded in time instead of stalling the game.