[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABob6ip_XykJbHfJ6nE6oAs3LtLTFRjKjc_1TK1puQSuNrJUMA@mail.gmail.com>
Date: Wed, 5 Jun 2013 08:31:01 +0200
From: Lukas Odzioba <lukas.odzioba@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: Phoronix Test Suite vs JtR
2013/6/5 Solar Designer <solar@...nwall.com>:
> It is very nice for our project's visibility that Phoronix uses JtR, but
> other than that people should be taking Phoronix's benchmark results
> (not only JtR, but in general) with a grain of salt. I tried contacting
> Michael on a few occasions to point out issues and better ways to use
> JtR in Phoronix benchmarks, but I never heard back. I gave up.
That's not good. Maybe we can at least post link to this topic to the
Phoronix Forum and someone else will be interested in fixing possible
issues.
> Wow. You got a reply? This does not match my experience. By what
> means did you contact Michael?
I just sent him an email with just one simple question about
possibility of making mistake in that chart.
Half an hour later I got the response.
> On Wed, Jun 05, 2013 at 12:28:24AM +0200, Lukas Odzioba wrote:
>> -not using -format option during -test, so all formats are benchmarked
>> but only 1 value is parsed from the results
>
> Not a big deal. Moreover, this gives some systems time to switch to the
> higher clock rate before the format we're interested in is benchmarked.
>From testers perspective it is actually a problem when I have to wait
3*3*4=36 (tests*runs*benchmark_time) minutes for the results,
especially when there is no need for that.
I believe that the issue you mentioned could be solved in a less invasive way.
> A reason to use custom builds is comparing C compilers at
> different optimization levels, but unfortunately the resulting numbers
> are misleading if (mis)interpreted as reflecting JtR performance for
> actual use.
Agree.
> OK. Yes, they have a ~25% performance hit for md5crypt (even relative
> to the expected single-core speeds), perhaps because of custom CFLAGS
> and maybe also because of possible regressions with gcc 4.8 (and need
> for tuning of the interleave factor by us for this gcc version, which we
> have not done yet...)
Unfortunatelly I do not have more time to investigate that now. Maybe
later after 1.8.0-jumbo release.
Thanks for the response,
Lukas
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.
