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

71–80 of 111 posts

Re: Is Rust stack-efficient yet?

#71

Post by tialaramex »

msbarnett wrote: post #39
ape4 wrote: post #38

Honest question - does this mean Rust isn't ready for production yet?

No. TFA points out there isn’t a gigantic performance sink or anything, just an infelicity in the code they’re generating. >> Does this mean Rust is slower than C++? > No. You can always write your Rust code carefully to avoid copies. Besides, all of this only comes out to a small percentage of the total instruction count. That being said, it's something we should fix, and which I'm working on.

As pointed out elsewhere in this comment tree, things living on the stack when they needn't can mean they don't fit and thus the program doesn't work, so the optimisation can matter for that reason, and this is a particular reason to worry about it for larger objects where the optimiser is more likely not to see what's going on.

Re: Is Rust stack-efficient yet?

#74

Post by dahfizz »

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…

It seems crazy to me that something as trivial as allocating heap space needs rust nightly and unsafe. And people want to rewrite the world in Rust.

Maybe in another ten years the language will mature.

Re: Is Rust stack-efficient yet?

#75

Post by msbarnett »

dahfizz wrote: post #74
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…

It seems crazy to me that something as trivial as allocating heap space needs rust nightly and unsafe. And people want to rewrite the world in Rust. Maybe in another ten years the language will mature.

> It seems crazy to me that something as trivial as allocating heap space needs rust nightly and unsafe.

It seems crazy to you because your spectacular misdescription of the problem is simply incorrect.

Re: Is Rust stack-efficient yet?

#76

Post by msbarnett »

tialaramex wrote: post #71
msbarnett wrote: post #39

Earlier quoted context omitted.

No. TFA points out there isn’t a gigantic performance sink or anything, just an infelicity in the code they’re generating. >> Does this mean Rust is slower than C++? > No. You can always write your Rust code carefully to avoid copies. Besides, all of this only comes out to a small percentage of the total instruction count. That being said, it's something we should fix, and which I'm working on.

As pointed out elsewhere in this comment tree, things living on the stack when they needn't can mean they don't fit and thus the program doesn't work, so the optimisation can matter for that reason, and this is a particular reason to worry about it for larger objects where the optimiser is more likely not to see what's going on.

And yet, real world production rust programs exist and measured performance is generally excellent.

People are acting like this graph they saw for the first time today means that Rust is running at sub-Ruby speeds, when even with these excess copies we already know, and have known for years how rust programs have been performing in real life.

That there is room for improvement here does not mean that the status quo was not already excellent.

Re: Is Rust stack-efficient yet?

#78

Post by Ericson2314 »

wmanley wrote: post #66
Ericson2314 wrote: post #42

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.

Easier said than done. You can already have: unsafe fn new_in_place(out: &mut MaybeUninit ) But you require unsafe code both to implement it (to project MaybeUninit) and to call it. For it to be safe to call the type system would have to encode the invariant that &out is initialised after the call. It becomes even more complicated if the operation can fail.

Yes, you do. This is the cost of doing business. I'm OK with it.

If one doesn't want to deal with imperative programming in all its glory, go write Haskell or something. (I do that too.)

Re: Is Rust stack-efficient yet?

#79

Post by insanitybit »

yawgmoth wrote: post #11

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.

This isn't related to heap allocations. It's about removing the cost of a stack variable being moved into another stack variable.

Re: Is Rust stack-efficient yet?

#80

Post by pcwalton »

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…

The problem here is that performing the optimization can change the semantics of the program, if you consider order of memory allocation to be part of the semantics. If the object you're creating itself has memory allocations within it, then allocating the box before constructing contents will change the order of the mallocs. C++ compilers will not do this optimization for this reason, though C++ has emplace so that the programmer can manually work around it. For this reason I think that it may be best to just introduce an emplace-like pattern for Rust as well.

If constructing the object doesn't have side effects, however, then we should be able to hoist the allocation at the optimizer level.

Post reply on HN