|
Message-ID: <20120114111011.GA8866@openwall.com> Date: Sat, 14 Jan 2012 15:10:11 +0400 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: binary ciphertext and salt alignment On Fri, Jan 13, 2012 at 07:07:57PM +0100, magnum wrote: > On 01/13/2012 11:34 AM, Solar Designer wrote: > > Right now, loader.c uses MEM_ALIGN_WORD for binary ciphertexts and > > salts. I am going to adjust this such that it will use 4 when the > > corresponding size (format->params.binary_size or .salt_size) is between > > 4 and ARCH_SIZE-1, and MEM_ALIGN_NONE if the size is less than 4. > > > > Sounds good? > > Yes! This is now implemented (in CVS). > On a related note, I once tried to establish (using google) what speed > penalties there are - if any - for various kinds of misalignment on a > modern intel CPU. But I came up with nothing. Maybe this is simply not > an issue even for our purposes. No, I think it is an issue. --save-memory=3 disables those alignments, though - along with hash tables - for truly memory-starved systems. > I suppose the following could possibly be different sorts of > misalignments affecting performance: > > 1. read/write misaligned 64-bit > 2. read/write 32-bit not aligned to 8 > 3. read/write 32-bit not aligned to 4 > > I would not be surprised if you know the answers. No, I don't readily know what exact penalties are incurred in what cases on what CPUs. I think these are best found out by testing. Of those cases you listed above, #2 should normally incur no penalty, whereas #1 and #3 should incur a penalty. I suspect that things will be the worst when the misaligned access crosses a cache line boundary and neither of the two cache lines is readily in L1 cache. So we get two cache line loads instead of one, which takes extra time and potentially even wastes cache space. Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.