Meeting: October 30, 2019
Lokathor opened this issue · 9 comments
Post your topics of discussion!
Perspective of using https://github.com/KhronosGroup/LLVM-SPIRV-Backend to generate shaders by compiling Rust code. cc @MaikKlein for rlsl
wow, that meeting is going to be short!
I would like to participate and discuss #60
I will attend, but have a cold so i will probably not say as much.
I recently was able to get a no_std binary working on Windows, but I'm not quite ready to actually present it yet.
A friendly reminder for people who don't reside in the US that daylight savings has changed, which means that the meeting is an hour earlier than you are used to. It starts now :)
For the meeting:
https://wiki.alopex.li/WhereRustcSpendsItsTime explains some of compile times
Participants:
-
Issue #60 (Part 1): Prevent fragmentation of the ecosystem due to lack of features in Rust Std
- @kabergstrom proposes creating a gamedev-centric Std variant
- Allocator wg is stalled because they cannot experiment with custom allocators in the Rust Std codebase
- @kabergstrom spoke to @repi (Embark) who mentioned not yet requiring custom allocators, but will probably do so in the future
- @kabergstrom will create an issue for custom allocators and what their requirements are. @kvark will add to it
- @kvark is going to ask a core contributor of Rust std about allocators
-
Issue #60 (Part 2): Debug runtime performance is terrible
- Issue 32 also covers this issue
- https://doc.rust-lang.org/cargo/reference/unstable.html#profile-overrides allows for optimisation of dependencies, but doesn't work for generics like collections
- Something similar happened with C++ STL due to its excessive usage of templates
- @Lokathor recommends using opt-level 1
- @Osspial mentioned that nightly has a feature for setting opt-level per feature
- glam was opted as a non-generic alternative for nalgebra
We recently switched all of our Rust code at Embark from nalgebra to glam (after some fixes & improvements) and couldn't be happier. Builds 15x faster for us and is significantly easier to debug and contribute to. Of course it is a much smaller API but that is what we like and what fits with our specific use cases.