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

[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.

[bitshifter]

Control over memory alignment, layout and usage

I was curious if there were any specific concerns with regards to control over memory alignment, layout and usage.

As far as I know, Rust's control over these things is on par with or in some cases is better than C++. See https://doc.rust-lang.org/reference/type-layout.html for specifics, where Rust improves on C++ is due to allocators being alignment aware so you can put over aligned types in a Vec or a Box no problem, unlike C++ where over aligned types need special handling when heap allocating.

The only missing feature I'm aware of is:

The align and packed modifiers cannot be applied on the same type and a packed type cannot transitively contain another aligned type. align and packed may only be applied to the default and C representations.

The main reason that isn't supported is the behaviour in C/C++ land isn't consistent between MSVC and GNU toolchains so it's not clear which way Rust should go for this specific feature.

[kvark]

Spoke to @Gankra a bit (thanks!), here are the findings:

• the allocators WG had the custom alloc stuff in scope for this year, but no progress was made, and the goal may be dropped
• a champion is needed to drive this forward
• one of the tough problems it depends on is Tracking Issue for RFC 213: Default Type Parameter Fallback rust-lang/rust#27336 , which had an RFC merged long ago, but now apparently a new one needs to emerge to address some issues
• may still be possible to expose <A> generic in collections without solving that issue, by following HashMap trick of having different default() from new(). Needs a buy-in from both the core team and the libs team, the former is hard to distract

I reached out to the team Zulip to find more answers.

[Lokathor]

Slightly Related: It turns out that actually using the alloc crate in a no_std binary cannot be done on Stable at this time. You must have a Nightly attribute for an allocation failure hook somewhere in your binary if you want to link in the alloc crate, which normally is provided by std.

• Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc) rust-lang/rust#51540

Which is... less than savory.

[kabergstrom]

I was curious if there were any specific concerns with regards to control over memory alignment, layout and usage.
As far as I know, Rust's control over these things is on par with or in some cases is better than C++.

I agree, alignment issues seem to be fairly solved at a language level. The only issue I'm aware of is that there is no way to override alignment for a specific Vec instance or other collection type, which can be useful when you can't change the contained type's attributes, for example. It can be required when filling GPU buffers. Not a common or important case for sure, usually you can just define a newtype.

[TimDiekmann]

Hello, member of the allocator wg here.

Currently the WG is blocked by rust-lang/wg-allocators#2 . There is a WIP PR, but not much progress has been made there lately: rust-lang/rust#65083.

Until this PR has landed, it is impossible to push upstream. Unfortunately, I assume that this fact deterred most of the participants of the WG.

Nevertheless, the WG has made many suggestions on how to design allocators. The best reference is the issue tracker of the WG. A second thing that makes the WG seem inactive is the fact that we have many proposals, but none have been accepted or rejected. For this @ErichDonGubler and I are currently testing an RFC-bot to make an FCP possible in the WG.

Since it is currently not possible to test the proposals upstream, I published a crate which implements many of the proposals to have a base to test. It would help the WG and me a lot if other users could test this crate to see if it meets the requirements for an allocator API. Any help is very appreciated!

Could somebody provide a short status on how this is going, and if we could help?

As mentioned above, the issue tracker is one way to track the status. Another possibility is to take a look at my linked crate.

[Wodann]

@repi, would @TimDiekmann's aforementioned crate be a viable option for Embark to implement all required custom allocators with?

[ozkriff]

fyi rust-lang/rust#77187 ("Support custom allocators in Box")