[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150817142355.GA31321@openwall.com>
Date: Mon, 17 Aug 2015 17:23:55 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: FMT_OMP_BAD
Kai, magnum -
Kai - you tend to over-quote. Please try to quote relevant context only.
On Mon, Aug 17, 2015 at 09:35:32PM +0800, Kai Zhao wrote:
> There are some dynamic formats below 4.0 or 7.0. Other than dynamic
> formats, there are 38 formats below 4.0 and 96 formats below 7.0. They
> are in the attached .txt file.
With "Only one salt" lines removed (which didn't correspond to unique
formats anyway), there are 19 formats below 4.0 and 55 below 7.0.
> What I need is to add FAST_FORMATS_OMP
> for the 38 formats which below 4.0, and add FMT_OMP_BAD for the
> 96 formats which below 7.0 ?
For 19 and 55, yes, with some exceptions:
Sybase-PROP is being discussed separately, see postings on it yesterday.
We should fix it to scale better.
wpapsk is in there by mistake. It's a slow format that should show good
OpenMP scaling, and it does when I test it now:
[solar@...er run]$ OMP_NUM_THREADS=1 ./john-omp -test -form=wpapsk
Warning: OpenMP is disabled; a non-OpenMP build may be faster
Benchmarking: wpapsk, WPA/WPA2 PSK [PBKDF2-SHA1 128/128 AVX 4x]... DONE
Raw: 1308 c/s real, 1308 c/s virtual
[solar@...er run]$ OMP_NUM_THREADS=10 ./john-omp -test -form=wpapsk
Will run 10 OpenMP threads
Benchmarking: wpapsk, WPA/WPA2 PSK [PBKDF2-SHA1 128/128 AVX 4x]... (10xOMP) DONE
Raw: 11560 c/s real, 1154 c/s virtual
There must have been some glitch during my benchmarks causing wpapsk to
appear to scale poorly.
It is weird that Raw-SHA1 and Raw-SHA1-ng would be treated differently,
even though they are in fact on different sides of the 4.0 threshold:
Ratio: 3.13780 real, 0.31346 virtual Raw-SHA1:Raw
Ratio: 4.45613 real, 0.46748 virtual Raw-SHA1-ng, (pwlen <= 15):Raw
I've just confirmed this with some benchmarks I ran. The most important
difference between these two is that -ng is limited to handling
passwords of up to 15 characters long only, which allows it to run
slightly faster. I'm unsure whether we want to add the compile-time
default for OpenMP support into the mix as well or not. I think our
options are: disable OpenMP by default only for Raw-SHA1 (as per the 4.0
threshold) or for both Raw-SHA1 and Raw-SHA1-ng (to treat them the
same). I think I'd prefer us to do the latter. Another reason to treat
them the same is that I suspect the better performance of -ng would be
less profound when running on a currently typical end-user machine with
4 physical cores and 8 logical CPUs. (We may confirm this.)
I'd like magnum's comments on this.
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.
