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.