[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20111214143742.GA372@openwall.com>
Date: Wed, 14 Dec 2011 18:37:42 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: OpenMP scheduling types & relbench
Hi,
I suspected that schedule(dynamic) would work better (than the typical
default of static) for some hash types and/or under load. I went to
test this for BF on a server under some unrelated load. To do this, I
made two builds of JtR 1.7.9 - one without changes and the other with
schedule(dynamic) added to the #pragma line in BF_std.c. The binaries
are actually slightly different:
text data bss dec hex filename
200535 12868 262048 475451 7413b john-s
200741 12880 262048 475669 74215 john-d
Then I ran this shell one-liner:
for n in {1..150}; do for j in s d; do ./john-$j -te=1 -fo=bf | sed "s/Raw/$n/" | tee -a $j; done; done
It does 150 benchmarks of each binary, taking 300 seconds (or 5 minutes)
total. And I can compare the resulting files with relbench:
Number of benchmarks: 150
Minimum: 0.62211 real, 0.84320 virtual
Maximum: 1.79539 real, 1.24042 virtual
Median: 0.99339 real, 0.99673 virtual
Median absolute deviation: 0.15013 real, 0.04577 virtual
Geometric mean: 0.98812 real, 0.99754 virtual
Geometric standard deviation: 1.23156 real, 1.06822 virtual
Well, it turns out that schedule(dynamic) did not result in any
improvement here, but it did not result in a significant slowdown
either. The benchmarking approach is sound and I think we may want to
run more tests like this - on different systems (with varying load and
no load), for different hash types, and for different scheduling clauses:
http://en.wikipedia.org/wiki/OpenMP#Scheduling_clauses
Also, I think that schedule(dynamic, 1) will actually be beneficial for
c3_fmt.c when running a wordlist against SHA-crypt hashes, because those
take non-constant time to compute (it depends on password length).
We'll need to confirm this.
In general, I think schedule(dynamic) should be harmless and potentially
beneficial for extra-slow hashes. It may also be OK for other slow
hashes. It is probably not OK for LM hashes and faster, where even a
large chunk of candidate passwords is very quick to process, so adding
any OpenMP scheduling overhead is not worth it.
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.
