Re: Big git diff speedup by avoiding x86 "fast string" memcmp

[Boaz Harrosh]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/