git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH] xdiff: Do not enable XDL_FAST_HASH by default

From
Anders Kaseorg <andersk@mit.edu>
Date
Dec 1, 2016, 04:30 UTC
Message-ID
<alpine.DEB.2.10.1611302329010.20145@buzzword-bingo.mit.edu>
In-Reply-To
<20161201035914.kftxb4vqmzcqed5r@sigill.intra.peff.net>

Although XDL_FAST_HASH computes hashes slightly faster on some architectures, its collision characteristics are much worse, resulting in some pathological diffs running over 100x slower (http://public-inbox.org/git/20141222041944.GA441@peff.net/).

Furthermore, it was being enabled when ‘uname -m’ returns x86_64, even if we are cross-compiling for a different architecture. This mistake was also causing the Debian build reproducibility test to fail (https://tests.reproducible-builds.org/debian/index_variations.html). Future architecture-specific definitions should be based on compiler macros such as __x86_64__ rather than uname.

Signed-off-by: Anders Kaseorg <andersk@mit.edu>
---

[Oops, also resending for Thomas’s new email address. Sorry for the spam.]

On Wed, 30 Nov 2016, Jeff King wrote:
Show 7 quoted lines
> However, I think this might be the tip of the iceberg. There are lots of
> Makefile knobs whose defaults are tweaked based on uname output. This
> one caught you because you are cross-compiling across architectures, but
> in theory you could cross-compile for FreeBSD from Linux, or whatever.
> 
> So I suspect a better strategy in general is to just override the
> uname_* variables when cross-compiling.

The specific case of an i386 userspace on an x86_64 kernel is important independently of the general cross compilation problem (in fact, the words “cross compilation” may not even really apply here). And I don’t think one should have to manually tweak the build for this setup, especially since the compiler already has the needed information.

> All that being said, I actually think an easier fix for this particular
> case might be to drop XDL_FAST_HASH entirely.
Works for me.
Anders
 Makefile         | 1 -
 config.mak.uname | 5 -----
 2 files changed, 6 deletions(-)
diff --git a/Makefile b/Makefile
index f53fcc90d..c237d4f91 100644
--- a/Makefile
+++ b/Makefile
@@ -341,7 +341,6 @@ all::
 # Define XDL_FAST_HASH to use an alternative line-hashing method in
 # the diff algorithm.  It gives a nice speedup if your processor has
 # fast unaligned word loads.  Does NOT work on big-endian systems!
-# Enabled by default on x86_64.
 #
 # Define GIT_USER_AGENT if you want to change how git identifies itself during
 # network interactions.  The default is "git/$(GIT_VERSION)".
diff --git a/config.mak.uname b/config.mak.uname
index b232908f8..2831a68c3 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -1,10 +1,8 @@
 # Platform specific Makefile tweaks based on uname detection
 
 uname_S := $(shell sh -c 'uname -s 2>/dev/null || echo not')
-uname_M := $(shell sh -c 'uname -m 2>/dev/null || echo not')
 uname_O := $(shell sh -c 'uname -o 2>/dev/null || echo not')
 uname_R := $(shell sh -c 'uname -r 2>/dev/null || echo not')
-uname_P := $(shell sh -c 'uname -p 2>/dev/null || echo not')
 uname_V := $(shell sh -c 'uname -v 2>/dev/null || echo not')
 
 ifdef MSVC
@@ -17,9 +15,6 @@ endif
 # because maintaining the nesting to match is a pain.  If
 # we had "elif" things would have been much nicer...
 
-ifeq ($(uname_M),x86_64)
-	XDL_FAST_HASH = YesPlease
-endif
 ifeq ($(uname_S),OSF1)
 	# Need this for u_short definitions et al
 	BASIC_CFLAGS += -D_OSF_SOURCE
-- 
2.11.0
Previous: Jeff King
Message 4 of 4 in “Define XDL_FAST_HASH when building *for* (not *on*) x86_64”
  1. Define XDL_FAST_HASH when building *for* (not *on*) x86_64Anders Kaseorg, Dec 1, 2016
  2. Jeff KingDec 1, 2016
  3. Jeff KingDec 1, 2016
  4. xdiff: Do not enable XDL_FAST_HASH by defaultAnders Kaseorg, Dec 1, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.