linux-kernel - RE: [PATCH v4 1/2] lib/test_bitops: Add benchmark test for fns()

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Sun, 5 May 2024 21:49:44 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Yury Norov' <yury.norov@...il.com>, Kuan-Wei Chiu <visitorckw@...il.com>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux@...musvillemoes.dk" <linux@...musvillemoes.dk>,
	"n26122115@...ncku.edu.tw" <n26122115@...ncku.edu.tw>,
	"jserv@...s.ncku.edu.tw" <jserv@...s.ncku.edu.tw>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v4 1/2] lib/test_bitops: Add benchmark test for fns()

..
> 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)