So c++ is less complicated than rust in some cases?
Should small Rust structs be passed by-copy or by-borrow? (2019)
191–200 of 238 posts
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#192This 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.
Even as someone who loves Rust, I completely agree with this. Rust is a niche tool, better suited for replacing C++ workloads than Python workloads
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#193Earlier quoted context omitted.
Blog author here. I somewhat agree, somewhat disagree. This line makes me uneasy: > I always ask them to either prove it or write the simple thing. If the code in question isn't hot enough to bother benchmarking it, the performance benefits probably aren't worth it _even if they exist_. One of my philosophies is that death by a thousand cuts is fine, but death by ten thousand cuts isn’t. A team of 10 engineers can pr…
Very little of your code is in hot loops. If the code that takes half a millisecond per frame could be twice as fast, but the hot loop is very optimized, then it doesn't really matter. And that's what I would think of by default for having many many cuts. Better to spend the optimization effort elsewhere. > shared_ptr is a canonical example of death by ten thousand cuts Why does that count as ten thousand cuts rather…
[deleted]
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#194Earlier quoted context omitted.
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.
That kind of problem doesn't happen in Rust though, because if all you have is a reference then you cannot mutate anything. You can only mutate things if you have a mutable reference to them, which makes the caller jump through hoops to acquire one for you. They may have to have ownership of the thing, or use a Mutex or RWLock to acquire exclusive access to it, before they can call your method. Nothing can be mutated by accident, or in a surprising place.
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#195Earlier quoted context omitted.
A question to the Rust experts, would lifetime annotations 'a in Rust have similar benefit as "in" or "in out" or "out" in Ada and other languages? With the additional benefit in Rust where the compiler can deduce those automatically for most cases?
As a sibling comment points out, "in" is effectively equivalent to "&T", and "inout" is effectively equivalent to "&mut T". Rust is missing purely "out" parameters, but that isn't a very common case, and I'm not sure how much value there is in saying "this reference can't be read" since references are always guaranteed to be valid in Rust.
A Rust program can trivially return a tuple of values, so it doesn't need out params.
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#196My first thought was "now what is the calling convention for float parameters again? they are passed in registers right? the compiler can probably arrange so they don't have to actually be copied" and then I realized it will probably even inline it. Anyway, assuming it's not inlined I would guess pass-by-copy, maybe with an occasional exception in code with heavy register pressure. Edit: Actually since it's a structu…
> Edit: Actually since it's a structure, the calling convention is to memory allocate it and pass a pointer, doh. So it should actually compile the same. FWIW the AMD64 SysV v1.0 psABI allows structures of up to 8 members to be passed via registers. Though older revisions limit that to 2 (and it's unclear whether MS's divergent ABI allows aggregates to be splat at all. As sad as it's unsurprising, it does not look li…
How can an abi allow but not require passing them via registers? Isn't the point of a convention that everyone does it the same way? Other wise the caller could put it on the stack and the callee look for it in a register?
Actually reading the word abi made a little neuron light up. To what extent does rust even follow that abi?
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#197Earlier quoted context omitted.
As a sibling comment points out, "in" is effectively equivalent to "&T", and "inout" is effectively equivalent to "&mut T". Rust is missing purely "out" parameters, but that isn't a very common case, and I'm not sure how much value there is in saying "this reference can't be read" since references are always guaranteed to be valid in Rust.
A Rust program can trivially return a tuple of values, so it doesn't need out params.
Out params are needed to ensure zero-copy in-place initialization of large objects, i.e. what C++ does with placement new. You can sort of fake it with MaybeUninit https://doc.rust-lang.org/std/mem/union.MaybeUninit.html but it's quite fiddly, requires unsafe code, and has undesirable effects on the layout of containing objects.
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#198Earlier quoted context omitted.
I just updated Visual Studio 2022 with all the latest updates and installed the Clang toolchain. I also updated Rust to latest. C++ MSVC: By-Copy: 12,077 By-Ref: 11,901 C++ Clang: By-Copy: 5,020 By-Ref: 5,029 Rust: By-Copy: 3,173 By-Borrow: 3,148 All on Windows, and on the same i7-8700k desktop I used for the original post in 2019. Your Rust numbers are particularly curious. Maybe run `rustup update` and try again?
Just did this rustup update. Much better now. So the finals are: Rust - By-Copy: 2685, By-Borrow: 2694 C++ - Windows MS Compiler - By-Copy: 12160, By-Ref: 11423 C++ - Windows LLVM 15 - By-Copy: 4397, By-Ref: 4396 My CPU is AMD Ryzen 5950X so it seems like Rust kicks the shit out of C++ in this case. I am going to try LLVM 16 and GCC tomorrow. Happy New Year
Happy new year! If you dig deeper post here, or feel free to e-mail me. username @ gmail
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#199Earlier quoted context omitted.
This seems to be an unpopular opinion, but I feel similarly about how sometimes people seem to toss out `inline` (and even more suspect, `inline(always)` annotations on Rust functions like candy on Halloween and there are almost never any sort of actual measurements of whether it actually helps in the cases it's used. It's not even that I think it really hurts that much in most of the stuff I've worked on (which tend…
Yeah inline is an absolute classic for this. The number of uncommented __attribute__((always_inline))s I see in C code drives me crazy. There are absolutely legitimate reasons to use that attribute but there should ALWAYS be a comment about why, so that later readers know in what conditions they can safely remove it.
In the old days I saw C code with massive overuse of the "register" keyword. Meaning this variable should be kept in a register. Someone had ove 12 of these in one function back when that was waaaay more variables then processors had registers.
Good thing modern register allocation by compilers makes this irrelevant.
Re: Should small Rust structs be passed by-copy or by-borrow? (2019)
#200A potential lesson here (i.e. I am applying confirmation bias to retroactively view this article as justification for a strongly held opinion, lol): Unless you are gonna benchmark something, for details like this you should pretty much always just trust the damn compiler and write the code in the most maintainable way. This comes up in code review a LOT at my work: - "you can write this simpler with XYZ" - "but that…
> I always ask them to either prove it or write the simple thing
This is cumulative thou, 1 may not make much difference. 100,000 of those will. There is that story of chrome slows down that was does discovered to be in strings each one of which is too little to make a difference