Messages in this thread | | | Date | Wed, 15 Dec 2010 15:15:09 +0200 | From | Boaz Harrosh <> | Subject | Re: Big git diff speedup by avoiding x86 "fast string" memcmp |
| |
On 12/15/2010 06:06 AM, Nick Piggin wrote: > > 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. >
I agree that the byte-compare or long-compare should give you very close results in modern pipeline CPUs. But surly 12 increments-and-test should show up against 3 (or even 2). I would say it must be a better plan.
BTW the long approach if you assume that the beginning of the string is long aligned than it is only a matter of comparing the last byte with a mask, no branches. But I'm not saying, just make sure they are padded.
Just my $0.017 Thanks Boaz
| |