[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABtNtWH40G-Xaa7CAQ+SN+oDR80oOHWgChBX8TfH=8_L-miLYA@mail.gmail.com>
Date: Mon, 17 Aug 2015 21:35:32 +0800
From: Kai Zhao <loverszhao@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: FMT_OMP_BAD
Hi Alexander,
On Mon, Aug 17, 2015 at 1:05 AM, Solar Designer <solar@...nwall.com> wrote:
> 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?
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. 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 ?
> 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.
Currently, there is only dynamic_fmt.c has FAST_FORMATS_OMP
but lack FMT_OMP_BAD. Should we add FMT_OMP_BAD for it ?
> 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,
Kai
View attachment "omp_bad.txt" of type "text/plain" (6527 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.
