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.