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

21–30 of 238 posts

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

#21

Post by daviddever23box »

ptero wrote: post #11

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

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

#22

Post by eloff »

m00dy wrote: post #8
eloff wrote: post #7

Earlier quoted context omitted.

What does this have to do with the operating system? There are no syscalls in the code measured here.

Because rust is a compiled language and therefore it means you compile your code to a certain architecture. Who told you about syscalls ? There are systems not using syscalls

There are no syscalls or equivalent operating system calls in the code paths measured. The architecture is also independent of the operating system, with exceptions in some languages for the calling convention (not in rust, afaik, or at least rust makes no guarantees there.)

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

#23

Post by furyofantares »

celeritascelery wrote: post #12

I 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 feel like they got excited by their C++ code being so much slower and curious about the "weird" C++ result and forgot to figure out the original question.

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

#24

Post by littlestymaar »

pclmulqdq wrote: post #9
eloff wrote: post #7

Earlier quoted context omitted.

What does this have to do with the operating system? There are no syscalls in the code measured here.

The dependency is on the ABI, which can be OS-dependent. Also, it is a depressingly manual optimization to do: compilers don't know when it is safe to change a reference to a copy (for example) without an analysis of future code that they don't do.

With Rust ownership guarantees, the compiler has the info it needs to perform this kind of optimizations.

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

#25

Post by pletnes »

sampo wrote: post #14
dwheeler wrote: post #3

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

Fortran also has «default» / no intent. This is somehow different from inout.

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

#26

Post by pclmulqdq »

littlestymaar wrote: post #24
pclmulqdq wrote: post #9

Earlier quoted context omitted.

The dependency is on the ABI, which can be OS-dependent. Also, it is a depressingly manual optimization to do: compilers don't know when it is safe to change a reference to a copy (for example) without an analysis of future code that they don't do.

With Rust ownership guarantees, the compiler has the info it needs to perform this kind of optimizations.

C and C++ are also set up such that the compiler can do that optimization, they just don't. I'm pretty sure the Rust compiler is in the same boat - has the information, but doesn't do the optimization.

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

#27

Post by fnordpiglet »

furyofantares wrote: post #23
celeritascelery wrote: post #12

I 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 feel like they got excited by their C++ code being so much slower and curious about the "weird" C++ result and forgot to figure out the original question.

To be fair I got excited too. But I still want to know the answer as well.

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

#28

Post by kolbe »

Anyone 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 rust--it's just a matter of how much work you need to put in to make it get there.

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

#29

Post by masklinn »

im3w1l wrote: post #4

My 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 like LLVM (linux?) has followed up, on godbolt a 2-struct passes everything via registers but a 3-struct passes everything via the stack. Maybe there's a magic flag to use the 1.0 ABI, but a quick googling didn't reveal one. ICC doesn't seem to have followed up either.

Post reply on HN