Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 25 Mar 2013 11:01:16 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: inlining strzncpy - and others?

On 24 Mar, 2013, at 13:04 , magnum <john.magnum@...hmail.com> wrote:
> On 24 Mar, 2013, at 12:20 , Solar Designer <solar@...nwall.com> wrote:
>>> I tested this briefly with strnzpy. The john binary grews with about 20 KB. A benchmark of raw-sha0 (using strnzpy in set_key) shows a one percent boost. That's not a lot but with slight boosts also in the rule engine, cracking modes and other parts of John it will add up to more.
>> 
>> This may be a fine change to make, but regardless I think we should also
>> review those uses of strnzcpy() where this matters, and try to optimize
>> them.  In rules.c, there are such uses in just 3 commands: 'x', '1', and
>> '2'.  Of these, maybe we only care about 'x' (since '1' and '2' are for
>> single crack mode only, which rarely runs for long and usually has other
>> bottlenecks anyway; there are also uses of strnz*() in single.c).  We
>> may try the strncat() trick for 'x' (need to benchmark it on multiple
>> systems/libc's).
> 
> I'll do some more testing. It looks like OSX' strncat is slower than the original strnzcpy, inlined or not :-/  Not that I care much about ultimate OSX performance.

It's not my libc - it's gcc's inlined replacement. I tried changing rules.c only. Despite strncat being inlined, inlining the original strnzcpy from misc.c (or even not inlining it) is faster. That was with a ruleset solely consisting of word pair or 'x' commands. I ran it with --single and with --wordlist. And the gain from inlining the original strnzcpy is minuscule - this is moot.

magnum

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ