All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Moinvaziri <nathan@nathanm.com>
To: Andy Shevchenko <andy@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] lib/string.c: Improve strcasecmp speed by not lowering if chars match
Date: Tue, 25 Oct 2022 17:53:49 +0000	[thread overview]
Message-ID: <BYAPR06MB557390C5F741300BDE2BAA8BD8319@BYAPR06MB5573.namprd06.prod.outlook.com> (raw)
In-Reply-To: <Y1embP5sEp/NPxK0@smile.fi.intel.com>

Hi Andy,

I appreciate your quick feedback!

I have done as you suggested and published my results this time using Google benchmark:
https://github.com/nmoinvaz/strcasecmp

After you review it, and if you still think the patch is worthwhile then I can fix the other problems you mentioned for the original patch. If you think it is not worth it, then I understand. 

Thanks again,
Nathan

-----Original Message-----
From: Andy Shevchenko <andy@kernel.org> 
Sent: Tuesday, October 25, 2022 2:04 AM
To: Nathan Moinvaziri <nathan@nathanm.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lib/string.c: Improve strcasecmp speed by not lowering if chars match

On Tue, Oct 25, 2022 at 11:00:36AM +0300, Andy Shevchenko wrote:
> On Tue, Oct 25, 2022 at 4:46 AM Nathan Moinvaziri <nathan@nathanm.com> wrote:

...

> > When running tests using Quick Benchmark with two matching 256 
> > character strings these changes result in anywhere between ~6-9x speed improvement.
> >
> > * We use unsigned char instead of int similar to strncasecmp.
> > * We only subtract c1 - c2 when they are not equal.

...

> You tell us that this is more preformant, but have not provided the 
> numbers. Can we see those, please?

So, I have read carefully and see the reference to some QuickBenchmark I have no idea about. What I meant here is to have numbers provided by an (open
source) tool (maybe even in-kernel test case) that anybody can test on their machines. You also missed details about how you run, what the data set has been used, etc.

> Note, that you basically trash CPU cache lines when characters are not 
> equal, and before doing that you have a branching. I'm unsure that 
> your way is more performant than the original one.

--
With Best Regards,
Andy Shevchenko



  reply	other threads:[~2022-10-25 17:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-25  1:46 [PATCH] lib/string.c: Improve strcasecmp speed by not lowering if chars match Nathan Moinvaziri
2022-10-25  8:00 ` Andy Shevchenko
2022-10-25  9:03   ` Andy Shevchenko
2022-10-25 17:53     ` Nathan Moinvaziri [this message]
2022-10-25 19:19       ` Andy Shevchenko
2022-10-27  3:29         ` Nathan Moinvaziri
2022-10-27  6:31           ` Andy Shevchenko
2022-10-25 19:32       ` Christophe JAILLET
2022-10-25 23:27         ` Nathan Moinvaziri
2022-10-25 19:55   ` Rasmus Villemoes
2022-10-25 22:37     ` Nathan Moinvaziri

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=BYAPR06MB557390C5F741300BDE2BAA8BD8319@BYAPR06MB5573.namprd06.prod.outlook.com \
    --to=nathan@nathanm.com \
    --cc=andy@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.