Should small Rust structs be passed by-copy or by-borrow? • Hacker News Board

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

#81

Post by pjmlp » Mon, Aug 26, 2019, 6:16 PM UTC

Crinus wrote: post #29

keeperofdakeys wrote: post #10

You should be careful trying to apply these micro benchmarks to modern optimising compiles, behaviour may be different depending on the exact code being compiled. Rust especially has immutability and known types in generics at compile time, so the compiler can do a lot of pointer and inlining magic that C and other languages can't. In the below example Rust switches to using a pointer when you might think it's doing…

> so the compiler can do a lot of pointer and inlining magic that C and other languages can't. Isn't this a negative for Rust for when you actually do care about such micro-optimizations? It feels as if you not only need to know the language itself but also how the particular version of the compiler you are using has decided to interpret the language and apply optimizations - essentially having to know how the magic…

Just like Ada has in, out and inout.

The actual generated code depends on the optimizer, while preserving semantics.

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

#82

Post by outworlder » Mon, Aug 26, 2019, 6:22 PM UTC

Kapura wrote: post #74

It's wild how much longer this article was than it needed to be. The first benchmark showed that for the test case tested, the copying and borrowing performed nearly identically. The answer to the stated question is that one is free to use whichever syntax one prefers. I would pick the one with the less-confusing semantics, as less complex code is more likely to be correct.

> It's wild how much longer this article was than it needed to be. The first benchmark showed that for the test case tested, the copying and borrowing performed nearly identically. The answer to the stated question is that one is free to use whichever syntax one prefers. I would pick the one with the less-confusing semantics, as less complex code is more likely to be correct.

Please don't blindly apply this line of reasoning everywhere.

For this particular micro-benchmark the results were almost identical. So for this particular piece of code one should apply whatever makes sense.

But if you are trying to generalize to other code (or worse yet, trying to come up with a rule), then you need to understand why the code is behaving the way it is. If you blindly trust your benchmarks you become blinded by their implicit assumptions.

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

#83

Post by fnord77 » Mon, Aug 26, 2019, 6:22 PM UTC

gopalv wrote: post #78

fnord77 wrote: post #77

> My answer to by-copy versus by-borrow for small Rust structs is by-copy The author is making the case for special treatment of structs for a special case. For a performance gain that's probably below the margin of error. This is negating the elegance and consistency of rust for a special case. I think the author thinks too much in C++ terms and is sort of missing the point of Rust (or at least one point of rust).

> The author is making the case for special treatment of structs for a special case. The struct by-copy is mostly a good API thing in a lot of scenarios, particularly when the objects are Even more so, when you're only writing half the code and want to separate the actions within a function from any side-effects outside. I would say that the performance difference for small structures is irrelevant to the extra hop,…

> Even more so, when you're only writing half the code and want to separate the actions within a function from any side-effects outside.

Due to the default immutability of references and the fact the compiler won't allow you to won't allow you to share data between threads (without jumping through a lot of hoops), the risk of side-effects are pretty well neutralized. Another selling point of Rust.

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

#84

Post by blub » Mon, Aug 26, 2019, 6:27 PM UTC

spease wrote: post #62

astrophysics wrote: post #48

This reminds me of the years I wasted writing C++, always looking for the idiomatic approach, rather than learning about security, networking, architecture and so on. In exactly the same way, Rust is just too complicated.

Rust is less complicated than C++, but it is more complicated than Go. However I’m a big proponent of minimizing complexity wherever possible - language overhead should not become an obstacle to programmer time. The nice thing about Rust is that it allows you to compartmentalize complexity very nicely by creating rules the compiler will enforce, whereas with C++ the programmer is also burdened with knowing them. I’m…

I recently realized that trying to order C++ and Rust precisely on a complexity scale is rather pointless and misleading, since it's obvious that they are in the same class of trickiness, but for different reasons.

If a significant number of the developers that come into contact with a language think it's hard, then... it's very likely hard.

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

#85

Post by blub » Mon, Aug 26, 2019, 6:31 PM UTC

pcwalton wrote: post #56

astrophysics wrote: post #48

This reminds me of the years I wasted writing C++, always looking for the idiomatic approach, rather than learning about security, networking, architecture and so on. In exactly the same way, Rust is just too complicated.

Rust is too complicated because you can choose to take parameters by-value or by-reference?

It's because:

a) the language designers decided to cram several paradigms into it, including a heavier than usual dose of functional.

b) most people don't want to get pedantic about resource management

c) the syntax is weird for people coming from the C language family

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

#86

Post by [deleted] » Mon, Aug 26, 2019, 6:38 PM UTC

vintermann wrote: post #28

richardwhiuk wrote: post #24

Earlier quoted context omitted.

Yes - even if you ask for pass by move, it might pass a reference for a large struct.

That's interesting, and a bit surprising. I know Ada does this, but it's explicit about only specifying semantics ("in, "out" or "in out") and letting the compiler decide. Surely C or C++ optimizers won't do this?

[deleted]

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

#87

Post by shmerl » Mon, Aug 26, 2019, 7:00 PM UTC

keeperofdakeys wrote: post #10

You should be careful trying to apply these micro benchmarks to modern optimising compiles, behaviour may be different depending on the exact code being compiled. Rust especially has immutability and known types in generics at compile time, so the compiler can do a lot of pointer and inlining magic that C and other languages can't. In the below example Rust switches to using a pointer when you might think it's doing…

C++ also has some copy elision: https://en.cppreference.com/w/cpp/language/copy_elision

This is a very obscure topic in general, and almost requires reading the C++ standard to understand it.

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

#88

Post by lukebitts » Mon, Aug 26, 2019, 7:04 PM UTC

weberc2 wrote: post #75

stefan_ wrote: post #8

This purports to discuss pass-by-copy or reference but ends up not discussing that particular issue at all since every single compiler naturally inlined and vectorized his trivial micro-benchmark. If you were to discuss the headline issue, I guess you could delve deep into calling conventions, register pressure, various instruction set extensions that compilers can abuse to carry the data.. or you take the compiler o…

I've mostly only dabbled in Rust, but I recall it being really difficult to pass data by copy in Rust. It seemed to want you to pass things by reference, especially if your type is meant to implement any prominent trait. It didn't matter if my type was an int, Rust seemed to want me to pass it by reference.

Do you have an example? Copying is only hard to the extent that you need to #[derive(Copy)] for your type, and ints are already Copy. I also don't see how other traits factor here.

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

#89

Post by shmerl » Mon, Aug 26, 2019, 7:04 PM UTC

anderskaseorg wrote: post #15

> Blech! Having to explicitly borrow temporary values is super gross. You can cut down on a lot of that by implementing basic operations (Add, Mul, etc.) for both value and reference types. impl Add for Vector3 { … } impl Add for Vector3 { … } impl Add for &Vector3 { … } impl Add for &Vector3 { … } (The first three can delegate to the last one, unless there are value-specific optimizations you want to apply.)

Does that essentially overload + for it?

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

#90

Post by pcwalton » Mon, Aug 26, 2019, 7:06 PM UTC

blub wrote: post #85

pcwalton wrote: post #56

Earlier quoted context omitted.

Rust is too complicated because you can choose to take parameters by-value or by-reference?

It's because: a) the language designers decided to cram several paradigms into it, including a heavier than usual dose of functional. b) most people don't want to get pedantic about resource management c) the syntax is weird for people coming from the C language family

I'm sure a lot of people don't care about explicitly managing resources! But there are a lot of people who do, and they need a language to use.