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

231–238 of 238 posts

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

#231

Post by jamincan »

nicoburns wrote: post #226
josephg wrote: post #151

Earlier quoted context omitted.

Sure but it’s easy to go overboard with this stuff. Reduce (fold) especially can be pretty hard to read in hairy situations. My general rule is that if you need fewer lines of code to implement your logic with a simple for loop, you probably should.

Yeah, I agree with that. Especially reduce/fold, which I find is almost always better written as loop. Filter would be a good example of the opposite for me: almost always much clearer written functionally.

I find I frequently use a combination - use map/filter to setup an iterator, and then reduce it in a loop.

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

#232

Post by FpUser »

FpUser wrote: post #230
dagome wrote: post #220

Earlier quoted context omitted.

Such stark difference in performance is really fishy and needs a deeper analysis. I just checked it with different compilers (all based on LLVM) and here are the results: rustc 1.58 (LLVM 13): By-Copy: 10804, By-Borrow: 7198 rustc 1.64 (LLVM 14): By-Copy: 7385, By-Borrow: 7328 rustc 1.66 (LLVM 15): By-Copy: 2667, By-Borrow: 2777 clang++ (LLVM 14): By-Copy: 2439, By-Ref: 2589 clang++ (LLVM 15): By-Copy: 2473, By-Ref:…

Is this Windows or Linux? Also what CPU? Your results for rust on LLVM15 are pretty much close to mine but clang++ on LLVM15 is almost twice as slow. I really want to find reason.

Never mind, figured it out:

  clang++ -O3 -mavx2 fts_cpp_copy_bench.cpp -o test.exe
this did it. The final score is:

  rust - By-Copy: 2683, By-Borrow: 2697
  c++ - By-Copy: 2577, By-Ref: 2600
so C++ seems a bit faster but not by much

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

#233

Post by FpUser »

forrestthewoods wrote: post #198
FpUser wrote: post #190

Earlier quoted context omitted.

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

No need to bother with LLVM16 and / or GCC. Enabling avx2 for Clang compiler produced following results that are more or less in line with what was expected.

  rust - By-Copy: 2683, By-Borrow: 2697
  c++ - By-Copy: 2577, By-Ref: 2600
Either is way faster than the result from the original post and no rust does non win this "competition". C++ is a bit faster (see also the results from other poster above) but not by much.

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

#234

Post by touisteur »

throwaway894345 wrote: post #228
touisteur wrote: post #223

Earlier quoted context omitted.

Ouch, I actually feel Ada was right in having the for-loop 'variable' be constant inside the body of the loop. If you want a modifiable loop variable, use a loop/while loop, but at least the first question in peer-review becomes 'why not a for-loop here'?

I don’t think that solves the problem because the loop itself still needs to mutate the variable. The issue often arises when people fork a new goroutine that closes over the loop variable inside the loop body—the loop often completes before any of the threads start running, so many/all of the threads read the loop variable at its max value (e.g., if we are forking 10 goroutines that just print their loop variable an…

Wouldn't any sane fork system capture the value of the loop variable instead of a reference to it? Why would anyone ever want to capture a reference to a loop variable that will be moved under one's feet? I'm sorry I'm struggling to understand what we're doing here and why.

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

#235

Post by throwaway894345 »

touisteur wrote: post #234
throwaway894345 wrote: post #228

Earlier quoted context omitted.

I don’t think that solves the problem because the loop itself still needs to mutate the variable. The issue often arises when people fork a new goroutine that closes over the loop variable inside the loop body—the loop often completes before any of the threads start running, so many/all of the threads read the loop variable at its max value (e.g., if we are forking 10 goroutines that just print their loop variable an…

Wouldn't any sane fork system capture the value of the loop variable instead of a reference to it? Why would anyone ever want to capture a reference to a loop variable that will be moved under one's feet? I'm sorry I'm struggling to understand what we're doing here and why.

No, the capturing is done by the closure and as far as I know capturing by reference is pretty standard for closures across languages. The forking system just runs the closure in a thread, agnostic to any capturing details.

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

#236

Post by josephg »

FpUser wrote: post #232
FpUser wrote: post #230

Earlier quoted context omitted.

Is this Windows or Linux? Also what CPU? Your results for rust on LLVM15 are pretty much close to mine but clang++ on LLVM15 is almost twice as slow. I really want to find reason.

Never mind, figured it out: clang++ -O3 -mavx2 fts_cpp_copy_bench.cpp -o test.exe this did it. The final score is: rust - By-Copy: 2683, By-Borrow: 2697 c++ - By-Copy: 2577, By-Ref: 2600 so C++ seems a bit faster but not by much

Are you enabling avx2 for rust as well? What arguments are you using for rust?

Try this:

    RUSTFLAGS="-C target-cpu=native" cargo run --release # or whatever
And:

    clang++ -O3 -march=native fts_cpp_copy_bench.cpp -o test.exe
arch=native will also activate SSE, MMX, and all the other goodies that modern CPUs have to offer.

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

#237

Post by FpUser »

josephg wrote: post #236
FpUser wrote: post #232

Earlier quoted context omitted.

Never mind, figured it out: clang++ -O3 -mavx2 fts_cpp_copy_bench.cpp -o test.exe this did it. The final score is: rust - By-Copy: 2683, By-Borrow: 2697 c++ - By-Copy: 2577, By-Ref: 2600 so C++ seems a bit faster but not by much

Are you enabling avx2 for rust as well? What arguments are you using for rust? Try this: RUSTFLAGS="-C target-cpu=native" cargo run --release # or whatever And: clang++ -O3 -march=native fts_cpp_copy_bench.cpp -o test.exe arch=native will also activate SSE, MMX, and all the other goodies that modern CPUs have to offer.

Sorry for being dumb, I thought I've enabled it in ./cargo/config.toml for rust. Checked it again and it appears that I did not (the file name was wrong). -march=native for CLang also did better than just avx2

  rust - By-Copy: 1831, By-Borrow: 1850
  c++ -  By-Copy: 2411, By-Ref: 2458
Interesting why Rust wins with such a large margin. Maybe will try to find out later.

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

#238

Post by throw10920 »

osigurdson wrote: post #112
throw10920 wrote: post #44

Earlier quoted context omitted.

In the vast majority of situations (1) you'll prematurely optimize in the wrong place and (2) yes the profiler will point to a single, easy-to-fix smoking gun. Situations otherwise are the exception, rather than the rule, and it takes an expert to (1) recognize those situations and (2) know exactly how to write optimized code in that situation. That's why "don't prematurely optimize" is a good rule of thumb - because…

Suggest acquiring the needed knowledge instead of applying dogma. The true root of all evil is unexamined dogma.

This is ridiculous. If you had the knowledge, you'd apply it, and you can't acquire it without practice, which is going to involve heuristics (which you falsely call "dogma" in order to ad-hominem my argument) like this one, which exists precisely because you need something for when you don't have the specialized domain expertise.

> The true root of all evil is unexamined dogma.

This is so absurd that it doesn't deserve a reply.

Post reply on HN