Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 25 Mar 2013 11:01:16 +0100
From: magnum <>
Subject: Re: inlining strzncpy - and others?

On 24 Mar, 2013, at 13:04 , magnum <> wrote:
> On 24 Mar, 2013, at 12:20 , Solar Designer <> 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.


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.