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

Should small Rust structs be passed by-copy or by-borrow? (2019)

forrestthewoods.com

Post reply on HN
Print view View original

121–130 of 238 posts

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#121

Post by klyrs »

forrestthewoods wrote: post #109
bjackman wrote: post #80

A potential lesson here (i.e. I am applying confirmation bias to retroactively view this article as justification for a strongly held opinion, lol): Unless you are gonna benchmark something, for details like this you should pretty much always just trust the damn compiler and write the code in the most maintainable way. This comes up in code review a LOT at my work: - "you can write this simpler with XYZ" - "but that…

Blog author here. I somewhat agree, somewhat disagree. This line makes me uneasy: > I always ask them to either prove it or write the simple thing. If the code in question isn't hot enough to bother benchmarking it, the performance benefits probably aren't worth it _even if they exist_. One of my philosophies is that death by a thousand cuts is fine, but death by ten thousand cuts isn’t. A team of 10 engineers can pr…

> But if you have ten thousand cuts you’re probably doomed. And those don’t show up cleanly in a flame graph.

I am reminded of the lovely nanosecond/microsecond talk by Grace Hopper. If your code does a little bit of setup and then spends all of its time in a single hotspot, fine. But if your code is full of microsecond-suboptimal speed bumps, you can probably hide your hotspot altogether. And a flat-ish flame graph looks fine: nothing stands out as a problem!

It's valuable to do micro-benchmarks, not just to hone your optimization skills, but to learn optimal patterns in your language of choice. Then, when you're "in the zone" and laying down new code, you just do the optimal thing reflexively. Or, when you're reviewing or rewriting something, those micro-hotspots jump out and grab your attention.

There's a reason that ancient software running on ancient hardware is way more responsive & snappy than what we have today. Laziness.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#122

Post by ok123456 »

Patrol8394 wrote: post #117
bjackman wrote: post #80

A potential lesson here (i.e. I am applying confirmation bias to retroactively view this article as justification for a strongly held opinion, lol): Unless you are gonna benchmark something, for details like this you should pretty much always just trust the damn compiler and write the code in the most maintainable way. This comes up in code review a LOT at my work: - "you can write this simpler with XYZ" - "but that…

This x 10000 ! If I had a dime for every time I provided this exact feedback in code reviews…I find surprising that a lot of devs in tech industry are obsessed with pointless micro optimizations and they don’t care about writing maintainable, testable simple code. My final comment is always to not outsmart compilers/jvm because they tend to do a much better job that developers. Please, don’t optimize unless you have…

This is true for application code. But, Rust is trying to sell itself as a systems language and an embedded language and a language you can write kernel modules in. Memory budget matters in these cases.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#123

Post by dahfizz »

Patrol8394 wrote: post #117
bjackman wrote: post #80

A potential lesson here (i.e. I am applying confirmation bias to retroactively view this article as justification for a strongly held opinion, lol): Unless you are gonna benchmark something, for details like this you should pretty much always just trust the damn compiler and write the code in the most maintainable way. This comes up in code review a LOT at my work: - "you can write this simpler with XYZ" - "but that…

This x 10000 ! If I had a dime for every time I provided this exact feedback in code reviews…I find surprising that a lot of devs in tech industry are obsessed with pointless micro optimizations and they don’t care about writing maintainable, testable simple code. My final comment is always to not outsmart compilers/jvm because they tend to do a much better job that developers. Please, don’t optimize unless you have…

It depends on your specialization, I guess. If you're making a website, a few microseconds here and there probably don't matter.

But in my field (Fintech), performance really does matter. Doing the simple, slow thing is just lazy and won't make it through review.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#124

Post by ReflectedImage »

scotty79 wrote: post #96
ReflectedImage wrote: post #89

Earlier quoted context omitted.

There are many many many ways you can express something and it's very likely that one of those ways is a DAG. The issue here is that you are writing C++ code rather than Rust code.

How do you express as a DAG a tree where nodes need to keep references to their children and parents? Two separate synced trees? Is it worth it? > The issue here is that you are writing C++ code rather than Rust code. How dare you! I'm writing TypeScript code! ;-) Rust is not Forth. I can write whatever I want and there's nothing wrong with that.

> How do you express as a DAG a tree where nodes need to keep references to their children and parents?

Rewrite your program in a form where it does not contain a tree.

If you want an actual tree as a data structure, see the trees crate.

> Rust is not Forth. I can write whatever I want and there's nothing wrong with that.

And other people write Haskell code in Python :p. If your code style doesn't match the language you are using you are going to have a lot of unnecessary friction.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#125

Post by stephencanon »

jb1991 wrote: post #34
sampo wrote: post #14

Earlier quoted context omitted.

> This is one advantage of Ada, where parameters are abstractly declared as "in" or "in out" or "out". Also Fortran has "in", "inout" and "out".

And Swift also has "inout" parameters.

But not “out” params, sadly.

It can return multiple values, so this doesn’t matter much for value types, but it would be nice to be able to specify that a pointer arg is an out-param sometimes and enforce that it is not read from while handling allocation in the caller.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#126

Post by Dylan16807 »

forrestthewoods wrote: post #109
bjackman wrote: post #80

A potential lesson here (i.e. I am applying confirmation bias to retroactively view this article as justification for a strongly held opinion, lol): Unless you are gonna benchmark something, for details like this you should pretty much always just trust the damn compiler and write the code in the most maintainable way. This comes up in code review a LOT at my work: - "you can write this simpler with XYZ" - "but that…

Blog author here. I somewhat agree, somewhat disagree. This line makes me uneasy: > I always ask them to either prove it or write the simple thing. If the code in question isn't hot enough to bother benchmarking it, the performance benefits probably aren't worth it _even if they exist_. One of my philosophies is that death by a thousand cuts is fine, but death by ten thousand cuts isn’t. A team of 10 engineers can pr…

Very little of your code is in hot loops. If the code that takes half a millisecond per frame could be twice as fast, but the hot loop is very optimized, then it doesn't really matter. And that's what I would think of by default for having many many cuts. Better to spend the optimization effort elsewhere.

> shared_ptr is a canonical example of death by ten thousand cuts

Why does that count as ten thousand cuts rather than one cut? That doesn't sound intractable to fix if you have months.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#127

Post by saghm »

throwaway894345 wrote: post #120
bjackman wrote: post #80

A potential lesson here (i.e. I am applying confirmation bias to retroactively view this article as justification for a strongly held opinion, lol): Unless you are gonna benchmark something, for details like this you should pretty much always just trust the damn compiler and write the code in the most maintainable way. This comes up in code review a LOT at my work: - "you can write this simpler with XYZ" - "but that…

I generally agree, but it’s also not obvious to me in Rust (or in Go) whether passing by reference or by copy is more maintainable or clear. I guess what I want is some guidance on what I should do by default, which you sort of give with “do what is more maintainable”, but I can’t tell what that means in practice (I’ve been told to default to pass-by-reference in the past because most traits take &self and not self).

I don't think one of them is more clear or maintainable universally, but in a lot of contexts, there might be an obvious choice. As a trivial example (that isn't quite fair given that the topic is about structs), it will almost never be more clear or maintainable to pass a shared reference to an integer (although there may be cases where a mutable reference might make sense). I don't think there's much need for one to have precedence over the other by default; if anything, I see the discussion about performance tradeoffs not being worth fretting about in the absence of actual measurement to be an argument _against_ one of them being inherently preferable.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#128

Post by chc »

rwaksmunski wrote: post #102
dwheeler wrote: post #3

This is one advantage of Ada, where parameters are abstractly declared as "in" or "in out" or "out". The compiler can then decide how to best implement it for that specific size and architecture.

A question to the Rust experts, would lifetime annotations 'a in Rust have similar benefit as "in" or "in out" or "out" in Ada and other languages? With the additional benefit in Rust where the compiler can deduce those automatically for most cases?

As a sibling comment points out, "in" is effectively equivalent to "&T", and "inout" is effectively equivalent to "&mut T". Rust is missing purely "out" parameters, but that isn't a very common case, and I'm not sure how much value there is in saying "this reference can't be read" since references are always guaranteed to be valid in Rust.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#129

Post by yobbo »

The Rust-test implements the traits Add, Sub, Mul by value. This makes the few references less important in the total test. The ergonomics argument is motivated by using these traits. Otherwise, references would have had the same ergonomics.

But also, the struct is 3x32 bits, and Rust auto-implements the Copy-trait for it. It is barely larger than u64, which is the size of the reference.

But life is only simpler when Copy and Clone can be auto-implemented.

Re: Should small Rust structs be passed by-copy or by-borrow? (2019)

#130

Post by nicoburns »

baby wrote: post #115
tested23 wrote: post #111

Earlier quoted context omitted.

Ugh, you are right but then someone comes and uses this to rationalize not including things like map, filter and reduce in a language because they are supposedly too complicated and you can just do it with a for loop

I work in a Rust codebase that uses a lot of functional functions, and I’ll say this: on average the imperative style takes less lines of code and less indentation. I also find it more readable personally, and idiomatic.

Functional iteration is good for the same reason we use for loops over while loops, and while loops over goto: they are more constrained, more clearly communicate intent, and are therefore easier to reason about.
Post reply on HN