[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5691814688994372a8302ad201e4d09f@smtp.hushmail.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
