Should have also tried pass-by-move .
Should small Rust structs be passed by-copy or by-borrow? (2019)
51–60 of 238 posts
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#52I would go with the version that gives the clean user interface (that is, by copy in this case). If it turns out that the other version is significantly more performant and this additional performance is critical for the end users consider adding the by-borrow option. The clarity of the code using a particular library is such an big (but often under-appreciated) benefit that I would heavily lean in this direction whe…
Agreed - and this applies in nearly every language: start simple, trust your compiler, and optimize only when performance becomes untenable.
I agree in general, but the side-effect of doing this is that no matter how fast your hardware gets, your software will always end up optimized to the new hardware. So over time your software gets slower and slower but performance stays consistent as hardware gets faster.
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#53Anyone know why seemingly knowledgeable people (like the person who wrote this article) don't use micro benchmarking frameworks when they run these tests? Also, whenever you do one of these, please post the full source with it. There's no reason to leave your readers in the dark, wondering what could be going on, which is exactly what I'm doing now, because there's almost no excuse for c++ to be slower in a task than…
> please post the full source with it.
There’s literally a section called Source Code…
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#54This is one of the problems I have with writing rust code. You have to think about so many mundane details that you barely have time left to think about more important and more interesting things.
Having written a lot of C, you spend basically all your time thinking about "mundane details", and worse, if you make a mistake, you often don't know you made a mistake until it's running on some customer's servers and you just got a ticket escalated 3 times up to you with vague information about crashes rarely happening. Good luck remembering which bit of code you wrote 6 months ago that may be causing the problem.
I'll take Rust shouting at me for missing "mundane details" any day of the week.
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#55I don’t feel like this gave a satisfactory answer the question. Since everything was inlined, the argument passing convention made no difference in the micro benchmarks. But what happens when it does not inline? Then you would actually be testing by-borrow be by-copy instead of how good rust is at optimizing.
I sort of agree and sort of disagree.
> Then you would actually be testing by-borrow be by-copy instead of how good rust is at optimizing.
I don’t think the question is actually: “what is faster in practice, a by-copy method call or a by-value method call”, I think the question is: “as an implementer, which semantics should I choose when I’m writing my function”.
For the second question: “Rust is usually pretty good at aggressively inlining, so… if you’re willing to trust Rust’s compiler, you’re often okay going with by-copy implementations, but you should keep an eye on it”. Whereas, as you note, for the first question it’s not an answer.
But, I do think if someone was going to put more work into it I’d be very curious what the answer to the first question is. If I’m choosing to implement with by-copy semantics and trusting the Rust compiler to hopefully inline things for me, I’d like to know the implications in the cases when it doesn’t.
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#56Earlier quoted context omitted.
Always curious how Ada solves ABI issue with such optimizations in place.
As long as the calling convention is deterministic from the declaration of the function it should be fine right?
If it's deterministic, the compiler cannot actually choose the best way to optimise it.
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#57This 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.
> 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".
So does Delphi / FreePascal
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#58Oh neat, that’s my blog. My old posts don’t resurface on HN that often.
Lots of criticism of my methodology in the comments here. That’s fine. That post was more of a self nerd snipe that went way deeper than I expected.
I hoped that my post would lead to a more definitive answer from some actual experts in the field. Unfortunately that never happened, afaik. Bummer.
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#59Anyone know why seemingly knowledgeable people (like the person who wrote this article) don't use micro benchmarking frameworks when they run these tests? Also, whenever you do one of these, please post the full source with it. There's no reason to leave your readers in the dark, wondering what could be going on, which is exactly what I'm doing now, because there's almost no excuse for c++ to be slower in a task than…
> please post the full source with it. There’s literally a section called Source Code…
I see now. I looked twice. I think most people stop after a section called "Conclusion" that ends with "Thanks for reading." It doesn't help that the formatting then leaves a large gap between sections that doesn't indicate there's more after that.
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#60Earlier quoted context omitted.
> please post the full source with it. There’s literally a section called Source Code…
I see now. I looked twice. I think most people stop after a section called "Conclusion" that ends with "Thanks for reading." It doesn't help that the formatting then leaves a large gap between sections that doesn't indicate there's more after that.
Fair!