| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <CAH5fLghi4jgS+MuG48aLnYb6N6_FOeR0pLCjG3z5XdLve5tdhQ@mail.gmail.com>
Date: Mon, 2 Jun 2025 16:40:04 +0200
From: Alice Ryhl <aliceryhl@...gle.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Burak Emir <bqe@...gle.com>, Kees Cook <kees@...nel.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>, Viresh Kumar <viresh.kumar@...aro.org>,
Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <benno.lossin@...ton.me>, Andreas Hindborg <a.hindborg@...nel.org>,
Trevor Gross <tmgross@...ch.edu>, "Gustavo A . R . Silva" <gustavoars@...nel.org>,
Carlos LLama <cmllamas@...gle.com>, Pekka Ristola <pekkarr@...tonmail.com>,
rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-hardening@...r.kernel.org
Subject: Re: [PATCH v10 4/5] rust: add find_bit_benchmark_rust module.
On Mon, Jun 2, 2025 at 4:32 PM Yury Norov <yury.norov@...il.com> wrote:
>
> On Mon, Jun 02, 2025 at 01:36:45PM +0000, Burak Emir wrote:
> > Microbenchmark protected by a config FIND_BIT_BENCHMARK_RUST,
> > following `find_bit_benchmark.c` but testing the Rust Bitmap API.
> >
> > We add a fill_random() method protected by the config in order to
> > maintain the abstraction.
> >
> > The sample output from the benchmark, both C and Rust version:
> >
> > find_bit_benchmark.c output:
> > ```
> > Start testing find_bit() with random-filled bitmap
> > [ 438.101937] find_next_bit: 860188 ns, 163419 iterations
> > [ 438.109471] find_next_zero_bit: 912342 ns, 164262 iterations
> > [ 438.116820] find_last_bit: 726003 ns, 163419 iterations
> > [ 438.130509] find_nth_bit: 7056993 ns, 16269 iterations
> > [ 438.139099] find_first_bit: 1963272 ns, 16270 iterations
> > [ 438.173043] find_first_and_bit: 27314224 ns, 32654 iterations
> > [ 438.180065] find_next_and_bit: 398752 ns, 73705 iterations
> > [ 438.186689]
> > Start testing find_bit() with sparse bitmap
> > [ 438.193375] find_next_bit: 9675 ns, 656 iterations
> > [ 438.201765] find_next_zero_bit: 1766136 ns, 327025 iterations
> > [ 438.208429] find_last_bit: 9017 ns, 656 iterations
> > [ 438.217816] find_nth_bit: 2749742 ns, 655 iterations
> > [ 438.225168] find_first_bit: 721799 ns, 656 iterations
> > [ 438.231797] find_first_and_bit: 2819 ns, 1 iterations
> > [ 438.238441] find_next_and_bit: 3159 ns, 1 iterations
> > ```
> >
> > find_bit_benchmark_rust.rs output:
> > ```
> > [ 451.182459] find_bit_benchmark_rust_module:
> > [ 451.186688] Start testing find_bit() Rust with random-filled bitmap
> > [ 451.194450] next_bit: 777950 ns, 163644 iterations
> > [ 451.201997] next_zero_bit: 918889 ns, 164036 iterations
> > [ 451.208642] Start testing find_bit() Rust with sparse bitmap
> > [ 451.214300] next_bit: 9181 ns, 654 iterations
> > [ 451.222806] next_zero_bit: 1855504 ns, 327026 iterations
> > ```
> >
> > Here are the results from 32 samples, with 95% confidence interval.
> > The microbenchmark was built with RUST_BITMAP_HARDENED=n and run on a
> > machine that did not execute other processes.
> >
> > Random-filled bitmap:
> > +-----------+-------+-----------+--------------+-----------+-----------+
> > | Benchmark | Lang | Mean (ms) | Std Dev (ms) | 95% CI Lo | 95% CI Hi |
> > +-----------+-------+-----------+--------------+-----------+-----------+
> > | find_bit/ | C | 825.07 | 53.89 | 806.40 | 843.74 |
> > | next_bit | Rust | 870.91 | 46.29 | 854.88 | 886.95 |
> > +-----------+-------+-----------+--------------+-----------+-----------+
> > | find_zero/| C | 933.56 | 56.34 | 914.04 | 953.08 |
> > | next_zero | Rust | 945.85 | 60.44 | 924.91 | 966.79 |
> > +-----------+-------+-----------+--------------+-----------+-----------+
> >
> > Rust appears 5.5% slower for next_bit, 1.3% slower for next_zero.
> >
> > Sparse bitmap:
> > +-----------+-------+-----------+--------------+-----------+-----------+
> > | Benchmark | Lang | Mean (ms) | Std Dev (ms) | 95% CI Lo | 95% CI Hi |
> > +-----------+-------+-----------+--------------+-----------+-----------+
> > | find_bit/ | C | 13.17 | 6.21 | 11.01 | 15.32 |
> > | next_bit | Rust | 14.30 | 8.27 | 11.43 | 17.17 |
> > +-----------+-------+-----------+--------------+-----------+-----------+
> > | find_zero/| C | 1859.31 | 82.30 | 1830.80 | 1887.83 |
> > | next_zero | Rust | 1908.09 | 139.82 | 1859.65 | 1956.54 |
> > +-----------+-------+-----------+--------------+-----------+-----------+
> >
> > Rust appears 8.5% slower for next_bit, 2.6% slower for next_zero.
> >
> > In summary, taking the arithmetic mean of all slow-downs, we can say
> > the Rust API has a 4.5% slowdown.
> >
> > Suggested-by: Alice Ryhl <aliceryhl@...gle.com>
> > Suggested-by: Yury Norov <yury.norov@...il.com>
> > Signed-off-by: Burak Emir <bqe@...gle.com>
> > +const BITMAP_LEN: usize = 4096 * 8 * 10;
> > +// Reciprocal of the fraction of bits that are set in sparse bitmap.
> > +const SPARSENESS: usize = 500;
>
> Is there any simple mechanism to keep C and rust sizes synced? (If no,
> not a big deal to redefine them.)
Rust can access constants from header files, so you can move it to a
header file.
> > +module! {
> > + type: FindBitBenchmarkModule,
>
> I think we agreed to have the type something less unique, like:
>
> Benchmark.
>
> > + name: "find_bit_benchmark_rust_module",
>
> What is the name policy for rust? Maybe a more human-readable name
> would work better here?
I don't think there's any particular policy for Rust. Name modules in
the same manner you would C modules.
> All the above are nits. Please have my
>
> Reviewed-by: Yury Norov [NVIDIA] <yury.norov@...il.com>
>
> Thanks,
> Yury
Alice
Powered by blists - more mailing lists