Skip to content

Ecosystem At Risk: Custom Allocators (and more?) in std #60

Closed
@kabergstrom

Description

@kabergstrom

To great joy, we have seen more and more industry capital being invested in Rust and its ecosystem recently. Relevant to this working group, game industry interest is picking up as the benefits of Rust are proven and heard. I would like to commend @AlexEne for the initiative to create this working group and arrange a forum to allow for game development interests to be formally represented in the community.

On this note, I would like to highlight a historic catastrophe of the C++ ecosystem in the game industry: the perpetual reinvention of the standard library. As I'm sure many of you are aware, C++ is the preferred language in the game industry, though the specific subset of language features used will vary between development houses. There is one constant though: No one is using the Standard Template Library, and most companies have developed their own proprietary version. This leads to a total breakdown in the open source ecosystem: sharing code is nearly impossible, as it would require pulling in a second standard library. While I do recognize that C++ has other deficiencies that lead to low trust in others' code and low rates of sharing, it is surely a contributing factor to the desolate land of game dev C++ open source contributions. The ambition of this working group, and the Rust core team generally, is surely to avoid any such future.

On this note, I would like to call upon friends in this working group to enumerate any observed deficiencies in existing standard library facilities so that we can work together with the library team to address these issues.

The first concrete point I would like to raise is that of custom allocators in standard library collections, something that should be very dear to any industry fellow aiming to reliably ship a demanding game. I am aware of the Allocator working group and relevant issues for std collections, for which I am very grateful, although after an initial burst of activity the group seems to have died down. The primary reasons for writing about this issue is to highlight the importance of this work and to call for increased participation across the community to hopefully hasten completion. Of course, it is important that we raise game industry specific concerns for allocators as soon as possible to ensure these can be addressed. Without support for custom allocators in collections, we risk industry users writing their own collections instead of contributing to the standard library.

I have yet to find a general summary of the current state of proposals, and generally anyone trying to contribute right now is probably best off starting by reading the issues in the allocator working group. I would also like to bring up the allocator issue in the next working group meeting.

Secondly, as game developers will surely be customizing collections and other parts of the standard library anyhow, I do believe that this working group should either

  1. Aim to centralize an effort for a "game dev standard library" that can act as an incubation point with lower barrier to entry before merging into the standard library eventually. This is with the reasoning that it is better to split the standard library ecosystem once, in the open, rather than once per company, behind closed doors.
  2. Document and ease the process of contributing to the Rust standard library. It hasn't been entirely clear to me how to do so without having to also recompile rustc.

For identifying further issues, and for those that would like more insight into the perspective of game developers in the industry, Electronic Arts has collected a great document containing reasoning for creating their custom standard library, listing many deficiencies in the C++ STL: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html

Some of the top concerns of game developers are generally:

  • Performance, both in release and debug builds
  • Control over memory alignment, layout and usage
  • Compile time
  • Debugger support

I would hope the Rust library team studies this issue extensively as we flesh it out. To emphasize the size of the game industry in terms of coding effort, I recently heard from a talk by Mike Acton that 50% of all C# globally is written for the Unity scripting engine, a single commercial game engine. It is not entirely unfathomable that parts of this effort will be redirected toward Rust in the future, and even better if some of that effort can be open sourced.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Long Term GoalIssues where we expect progress to be slow

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions