On Wed, 18 Oct 2006, Linus Torvalds wrote: > On Tue, 17 Oct 2006, Davide Libenzi wrote: > > > > Ehm, I think there's a little bit of confusion. The incorrect golden ratio > > prime selection for 64 bits machines was coalescing hash indexes into a > > very limited number of buckets, hence creating very bad performance on diff > > operations. The result of the diff would have been exacly the same, just > > coming out after the time for a cup of coffee and a croissant ;) > > But my point is, you would have been better off _without_ an algorithm > that cared about the word-size at all, or with just using "uint32_t". Yes. At the time I picked Knuth's hash function because it was simple and fast enough. But it needed special handling for different word sizes, exactly like kernel's hash_long() does. > A diff algorithm that gives different answers on a 32-bit LE architecture > than on a 64-bit BE architecture is BROKEN. If I run on x86-64, I want the > same answers I got on x86-32, and the same ones I get on ppc32. Anything > else is SIMPLY NOT ACCEPTABLE! Speaking in general, seen at the hash function level, of course an interface should not give different result for different word sizes or word endianess. Considering the diff algorithm as interface, as I said, the output was unaffected by the 64 bits word size. It was just very slow. - Davide - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html