[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8f461436eeb4bc130ac006a201c4624c@smtp.hushmail.com>
Date: Sun, 24 Mar 2013 13:04:24 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: inlining strzncpy - and others?
On 24 Mar, 2013, at 12:20 , Solar Designer <solar@...nwall.com> wrote:
> On Sun, Mar 24, 2013 at 03:16:17AM +0100, magnum wrote:
>> I just replaced Dhiru's four identical instances of inlined _memmem() with a shared jtr_memmem() in misc.h (using a faster implementation while at it) and made it 'extern inlined' as per the portable model described in http://www.greenend.org.uk/rjk/tech/inline.html (i.e. with function source in misc.h instead of misc.c).
>
> Now we have these warnings:
>
> In file included from unafs.c:8:0:
> misc.h: In function 'jtr_memmem':
> misc.h:149:7: warning: implicit declaration of function 'memcmp' [-Wimplicit-function-declaration]
Oops, fixed. It did not show in OSX.
>> Do you have any opinions or wisdom on such inlining?
>
> It might be the way to go, but so far I avoided it in part because we
> still try to support old C compilers that lack "inline". (Maybe we
> should not.)
We can tweak the current #if stack the same way but Jumbo contains "inline" in a lot of places anyway.
>> 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.
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.
