[<prev] [next>] [day] [month] [year] [list]
Message-ID: <4E2EE031.3040405@bredband.net>
Date: Tue, 26 Jul 2011 17:41:37 +0200
From: magnum <rawsmooth@...dband.net>
To: john-dev@...ts.openwall.com
Subject: Performance fluctuations
I'm trying to measure the performance boost from the "0010" patch but I
can't see any. In fact, it seems to drop by less than 1% (it definitely
should not). This brings up the old issue of fluctuations in performance
between runs of the exact same binary.
This quote is from an old private thread I had with Jim about --test
fluctuations:
On 2011-07-05 21:01, JFoug wrote:
> -test=10 hides 'some' of the variation. -test=4 if the system is more
> stable. I usually run on Winblos with a ton of other shit running
> Windows does not task switch 'too' smoothly, and the timing resolution
> is only 55ms. Thus, for a second or a couple seconds, the timing is
> flaky. I use 10s. You may be able to get by with less, but I think
> default john is 2 or 3s, and I have seen that simply not be enough.
> However, the code does look a little faster, and almost never slower.
I believe on Linux, the timing resolution is a couple of magnitudes
better than 55ms and I get the same amount of fluctuations whether I run
--test=1 or --test=20. Also, I have an idling dual core system and only
run john on one core. But it fluctuates wildly. I believe the code (many
formats) actually runs this much faster/slower between runs. This is an
interesting issue. It must have to do with how things end up in memory,
caches, alignment and so on. For a while when I made mskrb5 I used
__align__ heavily, not because it was needed but becuase I thought it
would stabilize things (always ending up aligned so a tad faster for
various operations) but in the end I dropped them because it did not
really help.
Another interesting thing is that more of the formats are rock stable
when compiled with icc. During development of the latest mscash2 (dcc2)
we had a version that would vary between 459-472 c/s when built with
gcc, but *always* 496 c/s when built with icc. I wonder what makes that
difference.
This is not just when running --test. I remember a set of test hashes I
used with a specific dictionary (much like the test suite we have now)
which would take anything between 30s and 1:30 to complete. I believe
the performance does not vary *within* a run, only *between* runs.
To sum it up, I would like to find ways to "help" the compiler produce
binaries with less fluctuating performance. Anyone have a clue? I tried
googling it to no avail.
magnum
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.
