Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Is Rust stack-efficient yet?

arewestackefficientyet.com

Post reply on HN
Print view View original

41–50 of 111 posts

Re: Is Rust stack-efficient yet?

#41

Post by adrian17 »

CapmCrackaWaka wrote: post #25
adrian17 wrote: post #13

Earlier quoted context omitted.

This is not about a heap-vs-stack tradeoff, this is about the compiler routinely generating very inefficient code that copies data around on stack for no good reason. For an example I've seen myself: using a custom GC pointer library, calling `Gc::allocate(SomeBigStruct{...})` constructed the SomeBigStruct on stack and copied it around using memcpy 4 times before it actually landed in the allocated heap memory. The e…

If you don't mind me asking - how do you witness these low level memory allocations? Specific program, plugin to vs code?

The simplest way to make quick experiments for me is with https://godbolt.org/ .

For my particular example: https://godbolt.org/z/8GvYzYj5h

You can see we're trying to put a 1kB object on heap, but the compiler generates two `memcpy` calls - first to copy it on stack to build the wrapper struct, second to actually copy the entire struct onto allocated memory.

In "real programs", you just need to look at the program's assembly. Or even more generally, I originally noticed this when observing the unusually high amount of time spent in some functions when profiling.

Re: Is Rust stack-efficient yet?

#42

Post by Ericson2314 »

We need &out and &in, so we can safely write this stuff by hand. Then we can worry about the compiler automatically optimizing to use &out behind the scenes (using ABI flexibility).

Trying to skip that first step, so the compiler just does unverified shit behind the scenes, I think will just end up with inflexibility and disappointment. Be the tortoise not the hare.

Re: Is Rust stack-efficient yet?

#43

Post by sitkack »

klodolph wrote: post #40

This affects the way you write code, too. I was writing something in Rust and I wanted to create a new boxed object. Box::new(...) Boom! Program crashes. The object I’m putting in the heap is too large for the stack. Rustc does this by instantiating the object on the stack, and then copying it to the box. I don’t really want to fuss with nightly or stuff like Box::new_uninit just to deal with this. C++ has both regul…

Box::new allocating on the stack and moving is only true in debug builds, in release builds it directly allocates on the heap. Not apologizing, just explaining. It is being fixed, the interim solution is to use a Vec.

Re: Is Rust stack-efficient yet?

#44

Post by conradev »

klodolph wrote: post #40

This affects the way you write code, too. I was writing something in Rust and I wanted to create a new boxed object. Box::new(...) Boom! Program crashes. The object I’m putting in the heap is too large for the stack. Rustc does this by instantiating the object on the stack, and then copying it to the box. I don’t really want to fuss with nightly or stuff like Box::new_uninit just to deal with this. C++ has both regul…

Bringing that feature to Rust was under discussion for a while but it was ultimately withdrawn:

https://github.com/rust-lang/rust/issues/27779#issuecomment-...

Re: Is Rust stack-efficient yet?

#45

Post by fb03 »

I'd appreciate if the graphs showed a larger span instead of every 4 hours and at most from a day ago (showing a flat line). It'd be very cool to see it spanning from months so that we could get a sense of the tendency of the line

Re: Is Rust stack-efficient yet?

#46

Post by throwup »

Murfalo wrote: post #15
throwup wrote: post #9

I've run into frustrating stack overflows in seemingly trivial non-recursive code, so I appreciate this effort! I wonder if it might be simpler to track stack sizes statically instead of using runtime instrumentation. What I mean is, for example on x86_64, the function prologue has a stack reservation in the form of `sub rbp, 0x168`. So we can easily tell that the function uses 0x168 bytes of stack space. Just add th…

It's not clear to me how this would track stack stack and memory stack copies. Can you explain?

My suggestion would not measure the copies themselves, but it would count how many bytes are the source/destination of copies (of course incl. other things like parameters/etc). It's not the exact same metric, but it does still help answer the question in the title. I would expect the two numbers to be highly correlated when building the same binary with different versions of the compiler.

It would also solve some practical problems mentioned in the page like the complexity of the setup and the speed of statistics gathering.

Re: Is Rust stack-efficient yet?

#47

Post by hmfrh »

CapmCrackaWaka wrote: post #25
adrian17 wrote: post #13

Earlier quoted context omitted.

This is not about a heap-vs-stack tradeoff, this is about the compiler routinely generating very inefficient code that copies data around on stack for no good reason. For an example I've seen myself: using a custom GC pointer library, calling `Gc::allocate(SomeBigStruct{...})` constructed the SomeBigStruct on stack and copied it around using memcpy 4 times before it actually landed in the allocated heap memory. The e…

If you don't mind me asking - how do you witness these low level memory allocations? Specific program, plugin to vs code?

Other than Godbolt Rust also has cargo-show-asm[1] that directly shows the actual assembly.

[1]: https://crates.io/crates/cargo-show-asm

Re: Is Rust stack-efficient yet?

#48

Post by ChadNauseam »

fb03 wrote: post #45

I'd appreciate if the graphs showed a larger span instead of every 4 hours and at most from a day ago (showing a flat line). It'd be very cool to see it spanning from months so that we could get a sense of the tendency of the line

OP mentioned on reddit that he’s planning on updating the graph with new data as he makes improvements

Re: Is Rust stack-efficient yet?

#49

Post by klodolph »

sitkack wrote: post #43
klodolph wrote: post #40

This affects the way you write code, too. I was writing something in Rust and I wanted to create a new boxed object. Box::new(...) Boom! Program crashes. The object I’m putting in the heap is too large for the stack. Rustc does this by instantiating the object on the stack, and then copying it to the box. I don’t really want to fuss with nightly or stuff like Box::new_uninit just to deal with this. C++ has both regul…

Box::new allocating on the stack and moving is only true in debug builds, in release builds it directly allocates on the heap. Not apologizing, just explaining. It is being fixed, the interim solution is to use a Vec.

There’s a broader problem here, which also applies to the C++ ecosystem, which is that debug builds are far less usable than they should be. C++ compilers in common debug configurations will emit a function call for std::move(), which is not in any way useful for typical debugging tasks and can make the program significantly slower.

I don’t want to rely on compiler optimizations to make my code work. Or alternatively, find a way to deliver those optimizations in debug builds.

The idea of using a Vec would be nice—if only the boxed item were an array! It’s a struct, you see…

Re: Is Rust stack-efficient yet?

#50

Post by pkolaczk »

bananapub wrote: post #31
pkolaczk wrote: post #27

Earlier quoted context omitted.

The optimizing backend for Rust and C++ is common. So if it didn't get optimized in Rust, it is very likely it wouldn't be in C++ as well. However, the code style of those two codebases might be different. IMHO C++ code is traditionally a lot more pointer and heap allocation heavy than Rust code. Rust makes moving stuff very convenient and using pointers/references quite inconvenient. Therefore showing heap allocatio…

> The optimizing backend for Rust and C++ is common. So if it didn't get optimized in Rust, it is very likely it wouldn't be in C++ as well. However, the code style of those two codebases eh? Rust doesn't have placement-new or specify copy elision. nothing at all to do with backends or "code style".

Sure it doesn't do placement new yet, but I think you're exaggerating the effect on lack of copy elision. Rust doesnt really need copy elision so heavily because it defaults to moving stuff, and move is just a very shallow copy taking typically one or two cycles. I've never seen it become visible in a profile.

In C++, copies are much more heavy, because they need to preserve the original, so copy elision matters a lot more. Also a developer is free to put arbitrarily complex stuff into a copy constructor. In Rust, those heavy copies are explicit so the developer can fully control when they happen.

Nevertheless - it could be all those reasons together. It's good someone is looking into it.

Post reply on HN