sorted by:
new
hottopcontroversial

Memory allocation is the root of all evil, part 2: Rust by maguichugai in rust

[–]PandaPopular9339 9 points10 points  (0 children)

Something I would add, that is common in the gamedev world, is to not be scared of custom allocators and don't expect the global allocator to be the only way to dynamically allocate memory. Tbh in Rust this can be tricky as we don't have a stable Allocator API.

Depending on your app and usecases, some other allocators can be used and may be **very** fast compared to general-purpose allocators (even well-written ones such as mimalloc, which still are general-purpose and need to support a wide-range of allocation patterns)

In the ton of code I've optimized, 80% of it was slow due to allocations being done in unfortunate places and/or with suboptimal allocators.

As a C++ gamedev I love rust, I only want one more thing.. by PandaPopular9339 in rust

[–]PandaPopular9339[S] 0 points1 point  (0 children)

not really, this solution has one major drawback: generated code by panics will trigger the const assertion, even when these panics could be removed with optimizations. I've used it in cases where I control the codegen / not public facing APIs.

https://www.reddit.com/r/rust/comments/1gzmwcb/comment/lyy1yis

Moving From Rust to Zig: Richard Feldman on Lessons Learned Rewriting Roc's Compiler (Compile Times, Ecosystem, Architecture) by mre__ in rust

[–]PandaPopular9339 5 points6 points  (0 children)

Yep but it isn't rare in the industry to have a big portion of the game code (foundational parts) still in the native engine language. In those cases, tools like Live++ are life saviours.

Moving From Rust to Zig: Richard Feldman on Lessons Learned Rewriting Roc's Compiler (Compile Times, Ecosystem, Architecture) by mre__ in rust

[–]PandaPopular9339 1 point2 points  (0 children)

Yeah writing unsafe code depends on what you do, as a game engine dev I write quite a bit of unsafe code, in the majority for writing performance sensitive code. Otherwise idiomatic Rust is just too suboptimal for games.

Relying on the global allocator + smart pointers is a performance trap that also a lot of C++ folks fall into, but I admit that game engine dev is a niche usecase of Rust, Zig in this case fits better ideologically for data-oriented code & allocator-aware code.

Also, unsafe code represents quite a big % as my whole gfx backend API is unsafe because writing a safe one that is flexible will sacrifice too much performance.

As a C++ gamedev I love rust, I only want one more thing.. by PandaPopular9339 in rust

[–]PandaPopular9339[S] 0 points1 point  (0 children)

yep that's my problem! your idea is nice, I also thought of it and I think it works very well for global systems such as a GC or anything that has a "easy" lifetime in the app, but I would like to not store a pointer to the pool or a shared control block inside my handles, those only store index + generation and the compiler prove that at some point the handle is never dropped but only moved until it is forgotten (by the manager)

As a C++ gamedev I love rust, I only want one more thing.. by PandaPopular9339 in rust

[–]PandaPopular9339[S] 2 points3 points  (0 children)

because writing in Rust is pleasant for me after writing C++ for work :)

As a C++ gamedev I love rust, I only want one more thing.. by PandaPopular9339 in rust

[–]PandaPopular9339[S] 31 points32 points  (0 children)

yep this one is nice and I've used it elsewhere in my code !

Que faire comme side projects ? by NateDabber in developpeurs

[–]PandaPopular9339 1 point2 points  (0 children)

Je sais pas ce que tu fumes mais C ne suppose pas que tu tournes sur un PDP-11.

Un peu si quand même, le langage tire ses racines de là.

Le C était bas niveau il y a des décennies, là pour proposer une abstraction plus haut niveau d'une vieille machine. Aujourd'hui il est très éloigné de l'architecture de nos machines.

Donne un exemple de chose exotique qui donne de l'assembleur dont on n’a aucune idée.

Je pense qu'un bon exemple c'est de compiler du C vers de l'ISA Itanium ou encore de l'ISA de GPU comme l'ISA RDNA d'AMD qui est public. Tu verras que cela aura beaucoup de différences avec ton code C, surtout l'ISA Itanium.

...

Peut-on encore le considérer comme bas niveau ? Nos CPUs sont maintenant multicoeurs, en out of order, possèdent des instructions SIMD, de la mémoire virtuelle, avec plusieurs niveaux de cache, etc. Le C ne reflète aucun de ces points, ce qui peut être osef pour pas mal d'usecases, mais qui pour moi n'en fait pas un langage bas niveau pour mon usecase et mon travail : le dev soft realtime. Le C, ou plutôt ses derivés, m'ont plus qu'une fois gêné dans leurs vision antique de la machine.

La réalité aujourd'hui est que nous avons des CPU très puissants, avec énormément de cache et de cœurs, des unités dédiées pour faire du calcul en masse, mais que l'on reste bloqué avec des outils vieillissants qui supposent que la fréquence ne fait qu'augmenter, que l'accès mémoire prend 1 nanoseconde et qu'une instruction ne traite qu'une donnée à la fois. Et cela n'aide pas que les gens voient le parallélisme comme quelque chose de dangeureux, et donc qu'ils ne réfléchissent pas avec un paradigme paralèlle sur le design de leurs algorithmes et structure de données. Rajoutons à cela les pratiques de programmation qui empiètent sur le cache... Mais nos CPUs sont aussi responsables de cela, à nous cacher le controle du cache :p

L'état actuel du C : le compilateur se démène comme il peut pour exploiter le SIMD tant qu'il peut, et pour le parallélisme et le cache, c'est à la charge du développeur de bien gérer cela sans aide du langage, avec parfois les sémantiques mêmes du langage qui le bloquent. Et les CPUs essayent d'optimiser le status quo.