Date: Thu, 17 Sep 2015 07:27:30 +0300 From: Solar Designer <solar@...nwall.com> To: john-dev@...ts.openwall.com Subject: Re: fast hash processing bottlenecks On Wed, Sep 16, 2015 at 09:37:54PM +0200, magnum wrote: > I think the rules engine has some low hanging fruit The best64 rules use repeated simple commands, instead of using some of our advanced commands. The attached patch optimizes our handling of that. With it, the best64 rules run faster, whereas our more typical rulesets continue to run at their usual speed. The 29M testcase is now down to: real 0m43.621s user 2m56.879s sys 0m17.599s It might make sense to further optimize this by having repeated $ and ^ commands translated into A commands when the rules are first parsed, like we do for no-op squeezing. A possibly more important optimization I didn't bother with yet is avoiding the copying from in to out in more commands, and instead moving the start of string pointer by a few chars. I didn't implement this so far because it's potentially problematic: a large number of rule commands would then be able to move the pointer to outside of its buffer. We'd need to check whether the pointer is still within bounds, and this would partially defeat the performance gain from the lack of copying. Alternatively, we could make the string buffers so much larger than the rule buffer that this issue would be impossible. (The start of string pointers would need to be placed in the middle of the buffers initially.) Alexander View attachment "john-repeated-rule-commands.diff" of type "text/plain" (3200 bytes)
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.