[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CACQBu=UQLHquztim+=ZGjS-EcQabQ7e2HPc9WEJXSJB1sQjGMA@mail.gmail.com>
Date: Sat, 26 Apr 2025 17:45:26 +0200
From: Burak Emir <bqe@...gle.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Boqun Feng <boqun.feng@...il.com>, Rasmus Villemoes <linux@...musvillemoes.dk>,
Viresh Kumar <viresh.kumar@...aro.org>, Miguel Ojeda <ojeda@...nel.org>,
Alex Gaynor <alex.gaynor@...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>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>, rust-for-linux@...r.kernel.org,
linux-kernel@...r.kernel.org, Rong Xu <xur@...gle.com>
Subject: Re: [PATCH v7 4/5] rust: add find_bit_benchmark_rust module.
On Sat, Apr 26, 2025 at 3:03 PM Yury Norov <yury.norov@...il.com> wrote:
>
> On Fri, Apr 25, 2025 at 06:17:59PM +0200, Burak Emir wrote:
> > On Fri, Apr 25, 2025 at 3:45 PM Boqun Feng <boqun.feng@...il.com> wrote:
> > >
> > > On Fri, Apr 25, 2025 at 02:20:13PM +0200, Burak Emir wrote:
> > > > On Fri, Apr 25, 2025 at 12:31 AM Boqun Feng <boqun.feng@...il.com> wrote:
> > > > >
> > > > > On Thu, Apr 24, 2025 at 09:48:17AM -0700, Boqun Feng wrote:
> > > > > > On Thu, Apr 24, 2025 at 06:45:33PM +0200, Burak Emir wrote:
> > > > > > > On Wed, Apr 23, 2025 at 6:56 PM Yury Norov <yury.norov@...il.com> wrote:
> > > > > > > > So? Can you show your numbers?
> > > > > > >
> > > > > > > For now, I only have numbers that may not be very interesting:
> > > > > > >
> > > > > > > - for find_next_bit, find_next_zero_bit and find_next_zero_bit (sparse):
> > > > > > > 22 ns/iteration in C, 32 ns/iteration in Rust.
> > > > > > >
> > > > > > > - for sparse find_next_bit (sparse):
> > > > > > > 60 ns/iteration in C, 70 ns/iteration in Rust.
> > > > > > >
> > > > > > > This is a VM running nested in a VM. More importantly: the C helper
> > > > > > > method is not inlined.
> > > > > > > So we are likely measuring the overhead (plus the extra bounds checking).
> >
> > Alice and I discussed that it may be better to do away with the extra
> > bounds check.
> > Micro benchmark, for the upcoming v8 that has the bounds check removed
> > (and the test changed to >=, as requested):
> >
> > [] Start testing find_bit() with random-filled bitmap
> > [] find_next_bit: 3598165 ns, 164282 iterations
> > [] find_next_zero_bit: 3626186 ns, 163399 iterations
> > [] Start testing find_bit() with sparse bitmap
> > [] find_next_bit: 40865 ns, 656 iterations
> > [] find_next_zero_bit: 7100039 ns, 327025 iterations
> > [] find_bit_benchmark_rust_module: Start testing find_bit() Rust with
> > random-filled bitmap
> > [] find_bit_benchmark_rust_module: next_bit:
> > 4572086 ns, 164112 iterations
> > [] find_bit_benchmark_rust_module: next_zero_bit:
> > 4582930 ns, 163569 iterations
> > [] find_bit_benchmark_rust_module: Start testing find_bit() Rust with
> > sparse bitmap
> > [] find_bit_benchmark_rust_module: next_bit:
> > 42622 ns, 655 iterations
> > [] find_bit_benchmark_rust_module: next_zero_bit:
> > 8835122 ns, 327026 iterations
>
> So I'm lost. You're going to keep those hardenings, but show the
> numbers without hardening on VM. Is that right?
No, I will remove the bounds checks where they are not needed for safety.
Indeed the latest are numbers without hardening in nested VM.
> Can you please show the numbers on bare-metal with the final
> configuration?
Sure, will include in v8 cover letter.
cheers,
Burak
Powered by blists - more mailing lists