[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aBCJQQWnQ-TRMECr@google.com>
Date: Tue, 29 Apr 2025 08:09:37 +0000
From: Alice Ryhl <aliceryhl@...gle.com>
To: Yury Norov <yury.norov@...il.com>
Cc: Burak Emir <bqe@...gle.com>, 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>, 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 Mon, Apr 28, 2025 at 09:21:40AM -0400, Yury Norov wrote:
> > By the way, if you add assert_eq!(bitmap.len(), BITMAP_LEN) before the
> > loop you may get the bounds checks optimized out.
>
> That sounds cheating, isn't?
>
> I think nobody will reject this series because of +15% in performance
> test, neither +25%, or whatever reasonable number.
>
> Let's just measure fair numbers and deliver clear maintainable code.
> There's a single user for bitmaps in rust so far, and it's you. So
> you're to call if performance is bad for you, not me. I just want
> to make sure that your numbers are withing the sane boundaries.
Right, well, in Binder's case the relevant performance comparison is a
single call to the bitmap's next_zero_bit vs following a sorted linked
list to find the first index that isn't used by an element in the list,
so I'm pretty confident that the bitmap will win no matter what.
Alice
Powered by blists - more mailing lists