bitshifter
commented
5 years ago 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
alignandpackedmodifiers cannot be applied on the same type and apackedtype cannot transitively contain anotheraligned type.alignandpackedmay only be applied to the default andCrepresentations.
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
Lokathor
kabergstrom
TimDiekmann
Wodann
ozkriff
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
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:
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.