Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.