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

161–170 of 238 posts

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

#161

Post by ReflectedImage »

scotty79 wrote: post #156
ReflectedImage wrote: post #124

Earlier quoted context omitted.

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

I think Rust is flexible enough to still work very well with my style. But you inspired me about something. I think I can rewrite the program that I am writing to use reverse Polish notation instead of a tree. Thanks!

Good luck!

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

#162

Post by dahfizz »

imron wrote: post #158
dahfizz wrote: post #123

Earlier quoted context omitted.

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.

Great. Should be easy to prove then.

Yup, we have a good benchmarking suite to make sure changes don't cause regressions and that optimization changes actually work.

That said, I think asking a developer to write everything they do twice so that they can A/B test is overboard. You can come back and really aggressively optimize later, but I think the "default" should be the fast thing, rather than the slow & easy thing.

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

#163

Post by mcguire »

This is one of those questions where you really, honestly, do need to look at a very low level.

Back in the ancient days, I worked at IBM doing benchmarking for an OS project that was never released. We were using PPC601 Sandalfoots (Sandalfeet?) as dev machines. A perennial fight was devs writing their own memcpy using dst++ = src++ loops rather than the one in the library, which was written by one of my coworkers and consisted of 3 pages of assembly that used at least 18 registers.

The simple loop was something like X cycles/byte, while the library version was P + (Q cycles/byte) but the difference was such that the crossover point was about 8 bytes. So, scraping out the simple memcpy implementations from the code was about a weekly thing for me.

At this point, we discovered that our C compiler would pass structs by value (This was the early-ish days of ANSI C and was a surprise to some of my older coworkers.) and benchmarked that.

And discovered that its copy code was worse than the simple dst++ = src++ loops. By about a factor of 4. (The simple loop would be optimized to work with word-sized ints, while the compiler was generating code that copied each byte individually.)

If you are doing something where this matters, something like VTune is very important. So is the ability to convince people who do stupid things to stop doing the stupid things.

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

#164

Post by forrestthewoods »

cogman10 wrote: post #114
ergonaught wrote: post #16

It's compiled, so, without any investigation at all, I would have been disappointed if there were any significant difference in the code emitted in these cases. I would expect the compiler to do the efficient thing based on usage rather than the particular syntax. I may have too much faith in the compiler.

At the VERY end of the article, the author points out "Oh, btw, I used MSVC for the C++ compilation, when I used clang things changed!" So, what the author actually measured was the difference between llvm and msvc throughout the article. Particularly when they talked about rust being better at autovectorization than C++.

Incorrect. Clang C++ vs MSVC C++ is very comparable, and noticeably worse for f64 by-ref. Clang C++ is still slower than Rust by a large margin. Using Clang C++ throughout would not change any conclusion (or lack thereof).

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

#165

Post by mcguire »

__turbobrew__ wrote: post #159
throwaway894345 wrote: post #120

Earlier quoted context omitted.

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 would still consider myself a go novice, but I have been burned a number of times passing simple objects by reference and then that object gets mutated causing subtle bugs. Also, go is happy to blow your foot off if you take the reference of a loop variable. Although, there is a proposal to fix that. Generally I find that less bugs get introduced when using copy instead of pass by reference, but I’m sure others hav…

I have had the same results. Passing by copy is simpler and less bug-prone and reduces the urge to "just set the value since I have a reference to the object" which is a well-paved road to significant pain.

And the objects have to get surprisingly large before passing by reference really makes a difference.

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

#166

Post by amelius »

scotty79 wrote: post #105
puffoflogic wrote: post #85

Earlier quoted context omitted.

Sibling and parent pointers are almost universally a sign that an abstract data structure (and associated algorithm) has been mistaken for concrete. The exception that comes to mind first is Knuth's dancing links, and its obscurity is an indication of the rarity of actually needing these pointers. In any case, it's also a poster child for using indices rather than pointers.

Currently I'm working on constructing proofs of tautologies directly from the system of axioms using substitution and modus ponens rule. https://en.m.wikipedia.org/wiki/List_of_Hilbert_systems Main objects in my program are expression trees. I manipulate them, cut them, merge them, compare them, splice one into the other. Rc's enable me to have full flexibility and share tremendous amount of data across objects in my…

> I'm not implementing specific algorithms. I'm making them up as I go

It's mindboggling to me that people are using a systems programming language for mathematical research, especially if they don't know yet what the final algorithms will look like.

But all the more power to you for trying.

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

#167

Post by 411111111111111 »

__turbobrew__ wrote: post #159
throwaway894345 wrote: post #120

Earlier quoted context omitted.

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 would still consider myself a go novice, but I have been burned a number of times passing simple objects by reference and then that object gets mutated causing subtle bugs. Also, go is happy to blow your foot off if you take the reference of a loop variable. Although, there is a proposal to fix that. Generally I find that less bugs get introduced when using copy instead of pass by reference, but I’m sure others hav…

This is about rust though and thats not really possible there (at least to my knowledge). You should get a compiler error if you attempt this.

I got very little experience in rust though, so there might be a way (I'm just not aware of) to circumvent this check

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

#168

Post by Dylan16807 »

klyrs wrote: post #143
Dylan16807 wrote: post #132

Earlier quoted context omitted.

> There's a reason that ancient software running on ancient hardware is way more responsive & snappy than what we have today. Laziness. Laziness in terms of using entirely inappropriate algorithms, sure. Laziness in not microbenchmarking minutia? It shouldn't be. There's a limit on how much that can hurt you. I would say much less than a factor of ten, but let's go with 10x just for argument's sake. If you have a CPU…

When I rewrite python code in C, I often hit 1000x speedups, and sub-100x is rare. And that's line-for-line. When I fix an accidentally-quadratic issue, for example, I've seen speedups in the billions without even changing the language. People have lionized Knuth's quote about premature optimization, and used that to ignore performance issues across the board. Since the early '00s, we have not seen a 500x improvement…

> When I rewrite python code in C, I often hit 1000x speedups, and sub-100x is rare. And that's line-for-line. When I fix an accidentally-quadratic issue, for example, I've seen speedups in the billions without even changing the language.

And neither of those is a microbenchmark thing, which is kind of my point. I'm surprised language would hurt that much, but that's enough to break things on its own without any layering.

> Since the early '00s, we have not seen a 500x improvement in CPU speed. It's less than 2x on frequency, and let's say 8x on core-count for most users (which doesn't help your single-core lazy programmer).

I don't think people are talking about 2004 when they talk about the responsiveness of ancient software on ancient hardware. I interpret that as more like an Apple II. But instructions per clock have also gone up a lot since the pentium 4 days, and having more than one core in your CPU has a huge impact even for single-threaded programs.

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

#170

Post by comex »

cwzwarich wrote: post #139
Diggsey wrote: post #94

Earlier quoted context omitted.

One neat thing here is that the compiler is aware of which types are `Copy` and not internally mutable (not contianing an `UnsafeCell`). For these types, passing `&T` and `T` are equivalent, so the compiler could just choose the faster option. Even if it's not smart enough to do that today, it could implement this optimization in the future. This could work even without inlining, since the Rust calling convention is…

It would be nice if Rust could do this, but it breaks backwards compatibility. Some existing code depends on pointer values of &T being equal or not equal.

As an addendum, LLVM can automatically perform the “&T-as-T” optimization (without inlining) in some cases where the callee function is in the same compilation unit and known to not care about the pointer value. However, these types of optimizations tend to be fragile, easily disturbed when things get slightly complex.
Post reply on HN