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

51–60 of 111 posts

Re: Is Rust stack-efficient yet?

#51

Post by codeflo »

kibwen wrote: post #22
codeflo wrote: post #12

Earlier quoted context omitted.

> No real guarantees around RVO / NRVO Shouldn’t Rust in theory have a lot more freedom in defining its calling conventions than C++ has? I wonder if there’s anything that prevents doing RVO by default, or if just hadn’t been a priority yet.

Evaluation order is unspecified in C++, whereas it is well-specified in Rust. This makes things easier to reason about in Rust, but does give the optimizer less wiggle room. https://en.cppreference.com/w/cpp/language/eval_order

How is evaluation order even relevant for RVO?

Re: Is Rust stack-efficient yet?

#52

Post by codeflo »

klodolph wrote: post #49
sitkack wrote: post #43

Earlier quoted context omitted.

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…

Having been bitten by that exact problem in C++, I think the original sin is to treat stuff like copy elision as a mere optimization, instead of a semantic guarantee.

Re: Is Rust stack-efficient yet?

#54

Post by klodolph »

codeflo wrote: post #52
klodolph wrote: post #49

Earlier quoted context omitted.

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…

Having been bitten by that exact problem in C++, I think the original sin is to treat stuff like copy elision as a mere optimization, instead of a semantic guarantee.

The C++ committee recognized this problem. As of C++17, copy elision is mandatory. Several forms of it, at least.

Re: Is Rust stack-efficient yet?

#55

Post by gpderetta »

klodolph wrote: post #49
sitkack wrote: post #43

Earlier quoted context omitted.

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…

fwiw, GCC now has -ffold-simple-inlines exactly for this issue.

Re: Is Rust stack-efficient yet?

#56

Post by tialaramex »

klodolph wrote: post #49
sitkack wrote: post #43

Earlier quoted context omitted.

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…

I guess what they mean is that the Vec would allocate heap space, and you could steal the allocation for your object to make the Box? You'd need to create this MyType manually and then tell Box what you made unsafely with like Box::from_raw()

It feels like a better way to do that directly with Box is Box::::new_zeroed() which will make you a Box> full of zero bytes. If MyType is definitely valid when made entirely of zero bytes and you're sure of that, you can unsafely assume_init() to have the MaybeUninit resolve to an actual MyType.

[[ If you lied, now everything is on fire, I did warn you that you need to be sure and it is an unsafe function ]]

If MyType is very much not valid if consisting entirely of zero bytes well, new_uninit() gives you memory in unspecified (must not be read) state, you can properly initialise it and then assume_init() as before - but all the extra work kinda sucks, and in either case clearly it would be nicer to just write what you meant and have it work.

Re: Is Rust stack-efficient yet?

#57

Post by klodolph »

gpderetta wrote: post #55
klodolph wrote: post #49

Earlier quoted context omitted.

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…

fwiw, GCC now has -ffold-simple-inlines exactly for this issue.

That’s not what -ffold-simple-inlines does. The -ffold-simple-inlines flag simply removes debugging information for certain inlined functions. It doesn’t affect whether the function is inlined in the first place. The result is that debug builds may have a smaller amount of debug information, but the code will be the same.

Re: Is Rust stack-efficient yet?

#58

Post by klodolph »

tialaramex wrote: post #56
klodolph wrote: post #49

Earlier quoted context omitted.

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…

I guess what they mean is that the Vec would allocate heap space, and you could steal the allocation for your object to make the Box? You'd need to create this MyType manually and then tell Box what you made unsafely with like Box::from_raw() It feels like a better way to do that directly with Box is Box:: ::new_zeroed() which will make you a Box > full of zero bytes. If MyType is definitely valid when made entirely…

I think the commenter made a guess that I was boxing an array, which is a good guess, it just happens to be wrong in this case.

Maybe that will work in the future—I don’t use nightly Rust, so for now, new_zeroed() won’t work. The basic problem is “I want to allocate something large on the heap” and it doesn’t seem like I should need to use nightly builds or unsafe{} to do it.

Re: Is Rust stack-efficient yet?

#59

Post by gpderetta »

klodolph wrote: post #57
gpderetta wrote: post #55

Earlier quoted context omitted.

fwiw, GCC now has -ffold-simple-inlines exactly for this issue.

That’s not what -ffold-simple-inlines does. The -ffold-simple-inlines flag simply removes debugging information for certain inlined functions. It doesn’t affect whether the function is inlined in the first place. The result is that debug builds may have a smaller amount of debug information, but the code will be the same.

That's not my reading of the docs, which explicitly talk about folding. Also simple tests shows that it does indeed inline the call even in debug mode.

In addition to inlining it also does also remove debug info.

Re: Is Rust stack-efficient yet?

#60

Post by Georgelemental »

conradev wrote: post #44
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-...

There is an open RFC that takes a different approach: https://github.com/rust-lang/rfcs/pull/2884
Post reply on HN