Date: Sat, 22 Aug 2015 05:20:57 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: BENCHMARK_LENGTH bugs On Fri, Aug 21, 2015 at 01:22:40PM +0800, Kai Zhao wrote: > On Fri, Aug 21, 2015 at 11:17 AM, Solar Designer <solar@...nwall.com> wrote: > > On Fri, Aug 21, 2015 at 11:03:19AM +0800, Kai Zhao wrote: > >> Could we define slow: whose speed is less than e.g. 1000K c/s ? > > > > As per the previous few messages, we shouldn't define slow for the > > purpose of your current work. Since this was merely correlation and we > > already know counter-examples, we shouldn't focus on this aspect. > > We should instead focus on whether the "Many salts" and "Only one salt" > > benchmarks results are expected to be different or almost the same. > > The benchmark_length should be 0 if the speedup from "Only one salt" > to "Many salts" is greater than 1%. Yes. > Otherwise, it should be -1. Is this right? Not exactly. e.g. 0.5% is still significant enough that I'd like to see it _if_ there are good reasons for this difference to exist. So the ultimate decision is based on our knowledge of what goes on under the hood (the "overkill" detail I provided to you) rather than on the difference between benchmarks on a given run. In other words, if the difference is reliably greater than 1% then we should run the two separate benchmarks and report their separate results. If not, then our decision may vary on a case by case basis. If the difference is extremely small - like all reported digits are literally the same - then we're very likely to want to mute the separate benchmarks. All of the above is for salted hashes only. For saltless, we obviously must never run these separate benchmarks. 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.