Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [day] [month] [year] [list]
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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ