Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 17 Dec 2011 09:21:19 -0700
From: RB <aoz.syn@...il.com>
To: john-dev@...ts.openwall.com
Subject: DES BS + OMP improvements, MPI direction

I've not been terribly active here lately, but certainly keep up with
the state of things and "evangelize" the use of JtR where appropriate.

That said, I wanted to congratulate and thank you guys for the recent
speed improvements.  Two specific items of note: the key setup for DES
bitslice and the proliferation of OpenMP enablement for various
hashes.  By itself, the DES improvement speeds up LM on benchmarks by
as much as 2x on one of my systems (W3565).  In concert with OpenMP, I
see between 120m and 180m c/s over four threads in live cracking
(using HT appears to dampen my specific performance), with completion
estimates in the 36-hour (!!!) range.  As bad as LM is, it's still
useful to those who have access to the SAM database.  OMP is just a
huge help in general.  I'm not seeing a linear increase in speed on my
systems, but it's enough to stick with 4/8/16-core machines and not
futz about trying to set up an MPI network any more.

All that said, after reading through the OMP additions they doesn't
appear to be terribly invasive.  I'm sure there's some necessary code
grooming prior to the seemingly small insertion of the pragma, but
overall it seems small.  I've not looked at the MPI stuff since magnum
took that over (thanks!), but that type of positioning is exactly
where I'd have wanted to go eventually.  Being partly lazy, are those
of you looking at the MPI implementation considering using that same
approach?  Assuming the network latency and throughput don't
interfere, that could certainly help solve the scaling issues john-MPI
had at the sunset of my maintainership.


RB

Powered by blists - more mailing lists

Your e-mail address:

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