Date: Sat, 23 May 2015 19:11:11 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: cycle around crypt_all() body in raw-sha512 Aleksey, On Sat, May 23, 2015 at 06:45:11PM +0300, Aleksey Cherepanov wrote: > My guess: switching between crypt_all() and candidate generation > in self tests is costly due to code cache, the cycle in crypt_all() > smooths it. Any comments? I've been using this "trick" in JtR since 1997 or so, initially for non-bitslice DES. Many of our formats use it. In many cases, it helps keep both key setup and salt setup out of the loop. Even when not, it may also help by amortizing the function call overhead. I think it's not about code cache in your case (you've got a decent N-way associative code cache), but about the function call overhead being higher than the loop overhead. You're reducing the total number of calls to crypt_all() and perhaps to cmp_all() that the program needs to make to test a given number of candidate passwords. Also, with the loop being within a function body, some variables may remain cached in registers across loop iterations - something that would be inconsistent with the ABI for function calls. 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.