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

101–110 of 111 posts

Re: Is Rust stack-efficient yet?

#101

Post by nayuki »

inferiorhuman wrote: post #98
codeflo wrote: post #85

Earlier quoted context omitted.

> But I have yet to see commercial projects with mixed skill level team members where using such libraries didn't lead to productivity reduction on the long run (independent of programming language). Mixed skill team or not, I really don’t see why Box should be something the language struggles with.

Agreed – but why would you want to box an array instead of simply using a Vec?

You can save memory by having fewer fields. This can matter when you have lots of small arrays.

Vec has {usize length, usize capacity, void* data}. Box has {usize length, void* data}. Box has {void* data}.

Re: Is Rust stack-efficient yet?

#102

Post by dathinab »

codeflo wrote: post #85
dathinab wrote: post #68

Earlier quoted context omitted.

Rust has also recognized the problem from a very early stage one. For example this is why there was a `box` operator in early rust. And e.g. placement-in like APIs had been in the works for years, it's just that no satisfying and sound solution has been found (but multiple solutions which initially seems sound). Which is why we currently are in a "hope the optimizer does the right thing" situations (through it is pre…

> But I have yet to see commercial projects with mixed skill level team members where using such libraries didn't lead to productivity reduction on the long run (independent of programming language). Mixed skill team or not, I really don’t see why Box should be something the language struggles with.

EDIT: I realized the TryFrom is just implemented for Box not Vec but you can easily convert a Vec to a Box. I updated the code accordingly.

vec![0u8; 1024*1024].into_boxed_slice().try_into().unwrap()

isn't that terrible to use

her as a function:

fn calloc_buffer() -> Box {

   vec![0u8; N].into_boxed_slice().try_into().unwrap()
}

I you want to rely a bit less on the optimizer using `reserve_exact()` + `resize()` can be a good choice. I guess it could be worthwhile to add a helper method to std.

Re: Is Rust stack-efficient yet?

#103

Post by inferiorhuman »

nayuki wrote: post #101
inferiorhuman wrote: post #98

Earlier quoted context omitted.

Agreed – but why would you want to box an array instead of simply using a Vec?

You can save memory by having fewer fields. This can matter when you have lots of small arrays. Vec has {usize length, usize capacity, void* data}. Box has {usize length, void* data}. Box has {void* data}.

For a typical use case that seems like a rather extreme optimization, no? If you have a lot of objects with many small arrays and you're keeping them in a Vec, they'll be on the heap. If you're dealing with a bunch of small parts of a big blob of binary data, you'd use slices and not create new arrays. If you're on an embedded system you're not likely to have an allocator anyways.

(without trying to be too argumentative) right? Or?

Edit since I've been throttled:

  For example it can make a difference between passing values per register or per
  stack in some situations. … But then for some fields where C++ is currently very
  prevalent it might matter all the time.
That's an interesting one I hadn't thought about (and I didn't realize that the register keyword was deprecated in C++17). In a rather broad sense I hope Rust catches on in the kinda niche stuff where C++ is often popular. For example I've only done a little bit of dabbling with Rust in an embedded context but overall I thought it brought a lot to the table.

Re: Is Rust stack-efficient yet?

#104

Post by dathinab »

inferiorhuman wrote: post #103
nayuki wrote: post #101

Earlier quoted context omitted.

You can save memory by having fewer fields. This can matter when you have lots of small arrays. Vec has {usize length, usize capacity, void* data}. Box has {usize length, void* data}. Box has {void* data}.

For a typical use case that seems like a rather extreme optimization, no? If you have a lot of objects with many small arrays and you're keeping them in a Vec, they'll be on the heap. If you're dealing with a bunch of small parts of a big blob of binary data, you'd use slices and not create new arrays. If you're on an embedded system you're not likely to have an allocator anyways. (without trying to be too argumentat…

yes but also no,

In some situations "optimizing smart pointers" to just be a single pointer size (Box) instead of two pointer sizes (Box) or instead of three pointer sizes (Vec) can make a difference.

For example it can make a difference between passing values per register or per stack in some situations.

Or it could make the difference of how many instances of the boxed slice fit efficiently into the stack part of a smallvec. Which if it's the difference between the most common number fitting or not fitting can make a noticeable difference.

Through for a lot of fields of programming you likely won't opt. to do such optimizations as there are more important things to do/better things to spend time optimizing at. But then for some fields where C++ is currently very prevalent it might matter all the time.

Re: Is Rust stack-efficient yet?

#105

Post by insanitybit »

yawgmoth wrote: post #93
insanitybit wrote: post #79

Earlier quoted context omitted.

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.

I mean, it's tangentially related, sure. It's also related to ML because computers run ML algorithms and computers run programs with stacks.

Re: Is Rust stack-efficient yet?

#106

Post by vgel »

inferiorhuman wrote: post #103
nayuki wrote: post #101

Earlier quoted context omitted.

You can save memory by having fewer fields. This can matter when you have lots of small arrays. Vec has {usize length, usize capacity, void* data}. Box has {usize length, void* data}. Box has {void* data}.

For a typical use case that seems like a rather extreme optimization, no? If you have a lot of objects with many small arrays and you're keeping them in a Vec, they'll be on the heap. If you're dealing with a bunch of small parts of a big blob of binary data, you'd use slices and not create new arrays. If you're on an embedded system you're not likely to have an allocator anyways. (without trying to be too argumentat…

In a system at $WORK I recently optimized a structure from String to Box (similar optimization to remove the 8 byte capacity field) and saved ~16Gb of memory. Granted, the program uses 100-200Gb of RAM at peak, but it still was a nice win for basically no work. It's also a semantic win, since it encodes "this string can't be mutated" into the type.

Re: Is Rust stack-efficient yet?

#108

Post by pjmlp »

int_19h wrote: post #95
pjmlp wrote: post #90

Earlier quoted context omitted.

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.

Re: Is Rust stack-efficient yet?

#109

Post by yawgmoth »

insanitybit wrote: post #105
yawgmoth wrote: post #93

Earlier quoted context omitted.

I became interested in stack performance specifically because I had to avoid heap allocations.

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.

Re: Is Rust stack-efficient yet?

#110

Post by int_19h »

pjmlp wrote: post #108
int_19h wrote: post #95

Earlier quoted context omitted.

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...
Post reply on HN