[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120418020338.GA13336@openwall.com>
Date: Wed, 18 Apr 2012 06:03:38 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Crowd-sourcing statistics and rules
On Wed, Apr 18, 2012 at 12:45:45AM +0200, Frank Dittrich wrote:
> I just did a few tests on my atom netbook (linux-x86-sse2i build).
...
> As you can see, DES takes a huge performance hit (the --mkpc=1 version
> has less than 1% of the original version's speed).
> This is to be expected, since the bitslice implementation doesn't make
> any sense with a simulated buffer size of 1.
>
> For dummy and bf, things look better.
> (If I would want to get exact statistics for bf, I would nevertheless
> use --format=bf without --mkpc=1, and replay everything with
> --format=dummy --mkpc=1.)
FWIW, you can reduce the performance hit from --mkpc=1 by building with
the normally non-optimal linux-x86-any target. It currently disables
the use of bitslice DES (in favor of JtR's own non-bitslice
implementation) and it similarly disables the computation of two bcrypt
hashes at a time (assuming that this target would be used e.g. on the
original Pentium, which we still have single-bcrypt assembly code for -
I wrote it in 1997 or 1998 and actually ran it on the original Pentium).
Indeed, things will be really slow, but maybe not as slow as they are
when you "downgrade" modern parallelized multi-hash code to --mkpc=1.
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.
