Re:Is Rust Stack-Efficient Yet?
by yawgmoth on Thursday November 17, 2022 @07:56AM
(#33638231)
I would love to see this for C#. Avoiding heap allocations was something I had to tackle as part of a simulation software. C# has a handful of GC generations, and GC gen1 is very fast, but it's still faster to pool things ahead of time.
[ Parent
| on HN ]
You can access C#'s GC metrics through `System.GC.GetTotalAllocatedBytes` and similar APIs. Maybe you can make a benchmark and tracker for it yourself!
Re:Is Rust Stack-Efficient Yet?
by insanitybit on Thursday November 17, 2022 @01:00PM
(#33642929)
This isn't related to heap allocations. It's about removing the cost of a stack variable being moved into another stack variable.
I became interested in stack performance specifically because I had to avoid heap allocations.
Re:Is Rust Stack-Efficient Yet?
by insanitybit on Thursday November 17, 2022 @09:13PM
(#33648974)
I mean, it's tangentially related, sure. It's also related to ML because computers run ML algorithms and computers run programs with stacks.
While I want to understand your point and welcome enlightenment, so far this conversation has just been kinda weirdly hostile.
Using structs, stack allocations (safe since C# 7.x) and native heap go a long way.
Many of the post C# 7 features have been used to improve .NET performance in techpower benchmarks, and rewrite runtime code from C++ into C#.
You can also use generic functions that take struct arguments instead of delegates to get something like STL. I wish there was some syntactic sugar in the language for that, too - basically, struct lambdas.
There is a bit of that with static lambdas, function pointers (unsafe), but still isn't quite what you want.
Well, until relatively recently, they wouldn't be able to desugar what I really want into underlying bits. But now that we have verifiable ref structs with ref fields in them in C# 11, it's a straightforward transformation. Might be worth a proposal, actually...