Do some science about perf impacts of local vs referenced variables
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Refactor
- Clarity
- Needs clarification
- Activity status
- Quiet
- Tech stack
- rust
- Domain
- performance
Research direction
Start with the two Rust entry points shown in the issue: do_something and do_something_in_place. Build rigorous benchmarks or inspect their compiled assembly under representative conditions, then compare the local-copy and in-place implementations and document a conclusive performance result.
Written by the indexing model from the issue text.
Description
Here are two implementations of the same function, one that does the computation in a local copy of the data, and one that acts in-place in the provided ref.
While playing with benchmarks for several of the library's algorithms, I started getting a hunch that the in_place version of functions like these have faster performance. Maybe because there's a cache miss penalty to making a lot of accesses to memory somewhere else, or maybe because when you make a local copy, the compiler knows that it doesn't need to be thread-safe, so is free to do all the computation in CPU cache and only write the final result to RAM instead of needing to wait for RAM IO on every operation. Or something. But I wasn't able to prove it to myself conclusively. So this task is to do some science -- rigorous benchmarking or analysis of compiled assembly -- to get a conclusive answer.
fn do_something(arr: &[u8; 1000]) -> [u8; 1000] {
let mut local_arr = arr.clone();
// some random expensive operations
for i in 1 .. 999 {
for j in i .. 999 {
local_arr[j] = local_arr[j-1] ^ local_arr[j] ^ local_arr[j+1];
}
}
local_arr
}
fn do_something_in_place(arr: &mut [u8; 1000]) {
// some random expensive operations
for i in 1 .. 999 {
for j in i .. 999 {
arr[j] = arr[j-1] ^ arr[j] ^ arr[j+1];
}
}
}
- Dominant language
- Rust
- Stars
- 25
- Forks
- 18
- Avg merge
- 16h 38m
- Merged PRs (30d)
- 3
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from bcgit/bc-rust
-
good first issue refactor
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Difficulty 4/5 3-5 days Newbie friendliness 58/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100