Live data from Hacker News

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

forrestthewoods.com

41–50 of 115 posts

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

#41

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?

> Surely C or C++ optimizers won't do this?

When they can prove it doesn't change the semantics on ways that violate the standard I think you will find that they do. Rust doesn't really have it's own optimizer after all, just a repurposed C/C++ one.

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

#42
post #34

A good rule is to let the caller decide. If input parameters are by-reference and the caller wants to make them by-reference, congrats, no problem. If caller wants the parameters to by a copy, they can create a clone and pass a reference. But if you impose the input parameters to by copy, there's no way back.

In Rust (end even C++ afaik) it usually makes more sense to let the callee decide. Does it need to own the value? -> Call by value. Does it only need to inspect or (visibly) mutate the value during the function call? -> Call by reference (modulo optimization concerns).

Functions can also be generic over references vs. move/copy semantics, e.g.:

    fn foo(frob: T) where T: Borrow {
      // Do something with frob.borrow()
    }
Due to monomorpization, foo is specialized for moves/clones when called as foo(frob) where frob is a value type or for borrows when called as foo(&frob). Similarly, you can use Clone, ToOwned or even Into for going in the opposite direction.

Whether such functions are good taste in general is debatable ;).

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

#44
post #29

Earlier quoted context omitted.

> 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…

In general Rust emphasises semantics over implementation side-effects. For example you use a pass-by-value because you're semantically moving ownership of the value to the function, not because the implementation may be faster/slower at the assembly level. Not nailing down the implementation is what allows the compiler to make so many optimisations. If you need concise pointer control, use the unsafe trapdoor built i…

>If you need fast number crunching use the specialised library for it, not by writing a magic for loop with just the right amount of statements in it.

There is always that group of people who are trying to do something for which no specialized library exists.

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

#45

> 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.)

This has irked me as well. Is there an acceptable way to make this less verbose?

A crate with a derive macro for example?

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

#46
The original question aside, it's awesome that Rust has the potential to be faster than C++ because its language semantics allow for more compiler optimizations. I'd thought it was slightly slower, but maybe that's just a temporary state because C++ has had so much time to get optimized.

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

#47
post #46

The original question aside, it's awesome that Rust has the potential to be faster than C++ because its language semantics allow for more compiler optimizations. I'd thought it was slightly slower, but maybe that's just a temporary state because C++ has had so much time to get optimized.

I don't think that's the case. The article is comparing wildly different compilers (Visual Studio and LLVM) which are inevitably going to give very different results. Comparing Rust with clang would be a more interesting comparison since they use the same back end.

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

#49
post #47
post #46

The original question aside, it's awesome that Rust has the potential to be faster than C++ because its language semantics allow for more compiler optimizations. I'd thought it was slightly slower, but maybe that's just a temporary state because C++ has had so much time to get optimized.

I don't think that's the case. The article is comparing wildly different compilers (Visual Studio and LLVM) which are inevitably going to give very different results. Comparing Rust with clang would be a more interesting comparison since they use the same back end.

The idea that Rust has the potential to produce faster binaries than C/C++ comes, I guess, mainly from the fact that (once the bugs in LLVM have been fixed) Rust will be able to apply restrict/noalias very liberally to the generated IR, facilitating optimizations by the compiler backend which are not possible in your usual C/C++ codebase.

But yes, in this case it probably came down to some more obvious cause like a wildly different compiler.

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

#50

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.

You're welcome to write Rust as non-idiomatically as you like! It might take a few lines of #[no-warn()] to silence the compiler, though...
Post reply on HN