[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150816170542.GA23218@openwall.com>
Date: Sun, 16 Aug 2015 20:05:42 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: FMT_OMP_BAD
Kai, magnum -
We're not making enough use of the FMT_OMP_BAD flag. When set, this
flag makes john print a warning informing the user of poor OpenMP
scalability of the current format, and suggesting the use of --fork.
Also, while our ./configure currently disables OpenMP for fast formats
(where scalability is poor) by default, and it has the
--enable-openmp-for-fast-formats option to override that, it uses a
separate mechanism to identify those formats: the FAST_FORMATS_OMP cpp
macro. We might not want a 100% overlap of these two sets of formats
(maybe it makes sense to enable OpenMP by default for a format e.g. with
70% efficiency on a typical machine, yet warn the user that this
efficiency is substantially worse than 100%). However, I think that one
of these sets must be strictly a subset of the other: namely, all
formats for which OpenMP is disabled by default should have FMT_OMP_BAD
set for them for when --enable-openmp-for-fast-formats is used. Perhaps
we should try and come up with a way to make this automatic.
Regarding the first problem, to identify more formats that are "bad", I
just ran on super:
./configure --enable-openmp-for-fast-formats --disable-opencl --disable-cuda
make -sj32
cd ../run
OMP_NUM_THREADS=1 ./john --test --format=omp | tee -a a1
OMP_NUM_THREADS=10 ./john --test --format=omp | tee -a a10
./relbench a1 a10
The output is:
Number of benchmarks: 403
Minimum: 0.72849 real, 0.07279 virtual
Maximum: 9.73847 real, 0.98054 virtual
Median: 6.47450 real, 0.64678 virtual
Median absolute deviation: 2.70666 real, 0.26688 virtual
Geometric mean: 5.05540 real, 0.51211 virtual
Geometric standard deviation: 1.87574 real, 1.85602 virtual
As you can see, a lot of formats scale poorly, and some have even
demonstrated negative scaling (the minimum is worse than 1.0).
To identify which ones, I ran:
./relbench -v a1 a10 | grep ^Ratio: | sort -nk2 > omp1to10.txt
The file is attached.
We may agree on two cut-off points: e.g. < 4.0 (out of ideal 10.0) for
disabling OpenMP in default builds, and < 7.0 for setting FMT_OMP_BAD.
For formats where we have two benchmarks (usually for Only one vs. Many
salts), use the faster one of these two (which should be Many salts).
Kai, would you take care of adding FMT_OMP_BAD to those formats that
score below 7.0 on their fastest result in the attached .txt file?
Would you also take care of adding FAST_FORMATS_OMP checks for formats
that score below 4.0 on their fastest result in the attached .txt file?
And test that this results in the intended behavior on two builds (with
and without --enable-openmp-for-fast-formats).
Also, introduce a script to detect formats that have FAST_FORMATS_OMP
checks, but lack FMT_OMP_BAD. This is a bug.
In this test, I compared an OpenMP-enabled build at different thread
counts (1 vs. 10). It would also be relevant to compare these against a
non-OpenMP build. For some formats, it may show substantially different
numbers than we're seeing for 1 thread in an OpenMP-enabled build (and
this will suggest there's a need for optimization for the slower one of
these two cases). In fact, for deciding on where to add
FAST_FORMATS_OMP checks, a comparison of non-OpenMP vs. 10 threads would
be more relevant than the above comparison for 1 vs. 10 threads.
Thanks,
Alexander
View attachment "omp1to10.txt" of type "text/plain" (25851 bytes)
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.
