From: David Laight <David.Laight@ACULAB.COM>
To: 'Yury Norov' <yury.norov@gmail.com>,
Kuan-Wei Chiu <visitorckw@gmail.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux@rasmusvillemoes.dk" <linux@rasmusvillemoes.dk>,
"n26122115@gs.ncku.edu.tw" <n26122115@gs.ncku.edu.tw>,
"jserv@ccns.ncku.edu.tw" <jserv@ccns.ncku.edu.tw>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH v4 1/2] lib/test_bitops: Add benchmark test for fns()
Date: Sun, 5 May 2024 21:49:44 +0000 [thread overview]
Message-ID: <9108af3e10234c49b6452df245ad3250@AcuMS.aculab.com> (raw)
In-Reply-To: <ZjfumT3gv9rzFBxw@yury-ThinkPad>
...
> He also chose to use random numbers to feed the fns(), and that's a
> reasonable choice. I see nothing wrong in his approach with the array,
> as well as what you proposed. But the test is done, and it works. If
> you think it's worth testing the function with your approach, feel
> free to submit your test, I'll take it just as well, and we'll have
> even better coverage.
Accessing a very large array is going to be affected by cache line
and TLB misses.
It wont really be entirely affected by implementation of the
function itself.
This is especially relevant for something that does really apply
to large memory blocks.
OTOH you don't want to repeatedly call the version that used
a binary chop with constant data - the branch predictor
will learn the pattern instead of getting if wrong 50% of the time.
A compromise would be to repeatedly process a short random
buffer enough times to get something measurable.
Although it is perfectly possible to use a cycle counter
(but not the x86 TSC) to time single function calls and
get repeatable answers that can actually be compared to
calculated values.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
next prev parent reply other threads:[~2024-05-05 21:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-01 13:20 [PATCH v4 0/2] bitops: Optimize fns() for improved performance Kuan-Wei Chiu
2024-05-01 13:20 ` [PATCH v4 1/2] lib/test_bitops: Add benchmark test for fns() Kuan-Wei Chiu
2024-05-01 16:29 ` Yury Norov
2024-05-05 13:11 ` David Laight
2024-05-05 18:48 ` Kuan-Wei Chiu
2024-05-05 20:39 ` Yury Norov
2024-05-05 21:49 ` David Laight [this message]
2024-05-01 13:20 ` [PATCH v4 2/2] bitops: Optimize fns() for improved performance Kuan-Wei Chiu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9108af3e10234c49b6452df245ad3250@AcuMS.aculab.com \
--to=david.laight@aculab.com \
--cc=akpm@linux-foundation.org \
--cc=jserv@ccns.ncku.edu.tw \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=n26122115@gs.ncku.edu.tw \
--cc=visitorckw@gmail.com \
--cc=yury.norov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox