Re: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop

From: SZEDER Gábor <szeder.dev@gmail.com>
Date: Jul 30, 2019, 20:56 UTC
Message-ID: <20190730205624.GR20404@szeder.dev>
In-Reply-To: <20190730200203.GA4882@sigill.intra.peff.net>

On Tue, Jul 30, 2019 at 04:02:03PM -0400, Jeff King wrote:

Show 24 quoted lines

> On Tue, Jul 30, 2019 at 03:49:38PM -0400, Todd Zullinger wrote:
> 
> > > Subtest 6 had an ordering issue. We do not know whether
> > > the problem is the code or the test result not keeping up
> > > with the code changes.
> > >
> > > --- expect      2019-07-30 16:56:36 +0000
> > > +++ actual      2019-07-30 16:56:36 +0000
> > > @@ -1,6 +1,6 @@
> > >  NULL
> > >  NULL
> > >  NULL
> > > +7c7cd714e262561f73f3079dfca4e8724682ac21 3
> > >  139b20d8e6c5b496de61f033f642d0e3dbff528d 2
> > >  d79ce1670bdcb76e6d1da2ae095e890ccb326ae9 1
> > > -7c7cd714e262561f73f3079dfca4e8724682ac21 3
> > 
> > I hit the same failure while building for Fedora on the
> > s390x architecture.  I have not dug into it much yet, but
> > perhaps this is an endianess issue?
> 
> Ah, of course. Our oid hashing is done by just picking off the first
> bytes of the sha1, and it doesn't care about endianness (because these
> are just internal-to-memory hashes).

Yeah.

> We _could_ reconcile that like this:

Do we really want that, though? It's a hashmap, after all, and the order of iteration over various hashmap implementations tends to be arbitrary. So an argument could be made that this test is overly specific by expecting a particular order of elements (and perhaps by checking the elements' oid as well), and it would be sufficient to check that it iterates over all elements, no matter the order (IOW sorting 'actual' before the comparison).

OTOH, this is not just any hashmap, but an oidmap, and I could imagine that there might be use cases where it would be beneficial if the iteration order were to match the oid order (but don't know whether we actually have such a use case).

> I
> wonder if it's appreciably less efficient. I'll bet I could nerd-snipe
> René into doing a bunch of measurements and explorations of the
> disassembled code. ;)

Maybe it shows up in an oidmap-specific performance test, but with all that's usually going on in Git hashmap performance tends to be negligible (e.g. it's rarely visible in flame graphs).