lkml.org 
[lkml]   [2010]   [Dec]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Big git diff speedup by avoiding x86 "fast string" memcmp
Date

Thank you for explanation.
I understood about padding zero tail bytes as an improvement or a
variation of the 'long *' approach. But I didn't write about it in my
previous mail. If I had written, you might not need to describe again.

I have also compared "repe; cmpsb" and __builtin_memcmp "in userspace".
And __builtin_memcmp shows faster and it looks like an approach of
mixing pointers. Although the code size grows, in source it will be
simple #define and it is already done in x86_32. Do you (or any other
x86 experts) think it is worth to try?


J. R. Okajima

Nick Piggin:
> What I meant is that a "normal" memcmp that does long * memory
> operations is not a good idea, because it requires code and branches
> to handle the tail of the string. When average string lengths are less
> than 16 bytes, it hardly seems wothwhile. It will just get more
> mispredicts and bigger icache footprint.
>
> However instead of a normal memcmp, we could actually pad dentry
> names out to sizeof(long) with zeros, and take advantage of that with
> a memcmp that does not have to handle tails -- it would operate
> entirely with longs.
>
> That would avoid icache and branch regressions, and might speed up
> the operation on some architectures. I just doubted whether it would
> show an improvement to be worth doing at all. If it does, I'm all for it.


\
 
 \ /
  Last update: 2010-12-15 07:01    [W:0.085 / U:3.336 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site