Nick Piggin: > Well, let's see what turns up. We certainly can try the long * > approach. I suspect on architectures where byte loads are > very slow, gcc will block the loop into larger loads, so it should > be no worse than a normal memcmp call, but if we do explicit > padding we can avoid all the problems associated with tail > handling. Thank you for your reply. But unfortunately I am afraid that I cannot understand what you wrote clearly due to my poor English. What I understood is, - I suggested 'long *' approach - You wrote "not bad and possible, but may not be worth" - I agreed "the approach may not be effective" And you gave deeper consideration, but the result is unchaged which means "'long *' approach may not be worth". Am I right? > In short, I think the change should be suitable for all x86 CPUs, > but I would like to hear more opinions or see numbers for other > cores. I'd like to hear from other x86 experts too. Also I noticed that memcmp for x86_32 is defined as __builtin_memcmp (for x86_64 is "rep cmp"). Why does x86_64 doesn't use __builtin_memcmp? Is it really worse? J. R. Okajima -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
