Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 5 Sep 2012 07:33:20 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: memory usage (was: [john-users] JTR against 135 millions MD5 hashes)

On Tue, Sep 04, 2012 at 05:06:38AM -0400, jfoug@....net wrote:
> Do the builds drop to binary align=1 on intel boxes?  We probably 
> should, or at least allow a compile define to get this, in case it 
> causes a slight runtime slowdown.  Even for salts, I think we should 
> drop to align=1 on systems allowing non-aligned access, and fix any 
> formats which core due to actually having alignment issues (such as SIMD 
> access).  The requires aligned systems (like sparc) but even there, it 
> might be better to have the default be 1, and fix any format with 
> issues.  Possibly it would be better with more than 1 default value.

Currently, mem_alloc_tiny() has:

#if ARCH_ALLOWS_UNALIGNED
	if (mem_saving_level > 2)
		align = MEM_ALIGN_NONE;
#endif

So alignments are only disabled at the heaviest memory saving level,
along with other performance-killing.  Maybe we should adjust this -
what happens at what memory saving level - although it'd be good to do
some performance testing first.

I don't like the idea of disabling the alignments at compile time.

Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ