Live data from Hacker News

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

forrestthewoods.com

61–70 of 115 posts

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

#61
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.

Right, but I'm not basing that purely on these benchmarks. The fact that C++ allows so much, which Rust doesn't, prevents you from transforming code in certain ways that might achieve better performance with identical behavior. I'd just never really thought about the implications of that before. Because of this, in theory, equivalent Rust and C++ code should asymptotically approach a place where Rust is faster, even though at the moment there are many other factors like comparative maturity of the ecosystems.

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

#62

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 not sure if I’d say that it’s more complicated than Python, since Python’s flexibility can in practice lead to creative but very hard-to-follow code.

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

#63

I've had a smaller but similar dive recently while working on embedded machine (32 bit) with Rust. Clippy was pushing me to use move/copy instead of reference for passing a [u8; 8]. I thought this strange on a 32bit machine so I dived in and it turned out the "rule" is supposed to be "up to 2 register sized" variables are supposed to be copied, anything bigger is supposed to be referenced. The trick here is that due…

Did you file a ticket?

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

#64

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

I was pleased to see that there is a fuckit.rs: https://docs.rs/fuckit/0.2.1/fuckit/ in the vein of fuckit.js, fuckit.py and libfuckit

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

#65
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 author posted a clang benchmark at the end of the article. It has pretty much the same performance as the MSVC one.

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

#67
post #59
post #54

I don't really understand the complaints in the 'ergonomics' section, this code won't even compile: fn dot_product(a: &Vector3, b: &Vector3) -> float { a.x*b.x + a.y*b.y + a.z*b.z } fn do_math(p1: &Vector3, p2: &Vector3, d1: &Vector3, d2: &Vector3, s: f32, t: f32) -> f32 { let a = p1 + &(&d1*s); let b = p2 + &(&d2*t); let result = dot_product(&(&b - &a), &(&b - &a)); } Namely, how are you going to multiply a struct l…

> Namely, how are you going to multiply a struct like d1 by an f32? https://en.wikipedia.org/wiki/Scalar_multiplication Here's a Rust Playground with the vector math impls he's probably assuming (dummied): https://play.rust-lang.org/?version=stable&mode=debug&editio...

Oh yeah. It wasn't clear from the blog post that he had implemented some of the std::ops operators for his Vector3 struct.

You can get rid of the superfluous & symbols by implementing for &Vector3 also, so again, the ergonomics section doesn't really resonate with me.

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

#69

Earlier quoted context omitted.

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.

Then they'll use ASM, manual SIMD or pointers arithmetic like they would do in C and that would work. All of theses are part of the unsafe Rust (inline ASM is nightly only though, but you can still link to a ASM file even in stable).

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

#70
The article is interesting, but it is frustrating that it mainly cares about speed, but 'speed' or 'fast' is not mentioned in the title.

To answer that general title question, I would not even have considered that 'speed' might be an issue. I'd say: pass small things by value because it probably results in the most readable code, which should always be the first dimension of optimisation, I think. Also, the compiler is most probably good enough anyway, so care about your source code readability first.

So, at least the title should say 'if you care about speed a lot'.

Post reply on HN