Re: [PATCH v4 08/23] ewah: compressed bitmap implementation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jan 23, 2014 at 09:53:26PM +0000, brian m. carlson wrote:

> On Thu, Jan 23, 2014 at 03:26:45PM -0500, Jeff King wrote:
> > Looking over the format, I think the only thing preventing 4-byte
> > alignment is the 1-byte XOR-offset and 1-byte flags field for each
> > bitmap. If we ever have a v2, we could pad the sum of those out to 4
> > bytes. Is 4-byte alignment enough? We do treat the actual data as 64-bit
> > integers. I wonder if that would have problems on Sparc64, for example.
> 
> Yes, it will.  SPARC requires all loads be naturally aligned (4-byte to
> an address that's a multiple of 4, 8-byte to a multiple of 8, and so
> on).  In general, architectures that do not support unaligned access
> require natural alignment for all quantities.

In that case, I think we cannot even blame Shawn. The ewah serialization
format itself (which JGit inherited from the javaewah library) has 8
bytes of header and 4 bytes of trailer. So packed serialized ewahs
wouldn't be 8-byte aligned (though of course he could have added his own
padding to each when we have a sequence of them).

-Peff
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]