Re: [PATCH] git gc: Speed it up by 18% via faster hash comparisons
- From
Pekka Enberg <penberg@cs.helsinki.fi>
- Date
- Apr 28, 2011, 10:10 UTC
- Message-ID
- <4DB93D16.4000603@cs.helsinki.fi>
- In-Reply-To
- <BANLkTim+Kk_ah_4+pQKCi8bXtA8thRVRjQ@mail.gmail.com>
On 4/28/11 12:50 PM, Erik Faye-Lund wrote:
Show 8 quoted lines
>> Alas, i have not seen these sha1 hash buffers being allocated unaligned (in my >> very limited testing). In which spots are they allocated unaligned? > > Like I said above, it can happen when allocated on the stack. But it > can also happen in malloc'ed structs, or in global variables. An array > is aligned to the size of it's base member type. But malloc does > worst-case-allignment, because it happens at run-time without > type-information.
I'd be very surprised if malloc() did "worst case alignment" - that'd suck pretty badly from performance point of view. However, if you want *guarantees* about the alignment, there's memalign() for heap allocations.
Stack allocation alignment is a harder issue but I doubt it's as bad as you make it out to be. On x86, for example, stack pointer is almost always 8 or 16 byte aligned with compilers whose writers have spent any time reading the Intel optimization manuals.
So yes, your statements are absolutely correct but I strongly doubt it matters that much in practice unless you're using a really crappy compiler...
Pekka