[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BLU0-SMTP141591B38A2C4F967F22306FD270@phx.gbl>
Date: Sat, 5 Jan 2013 11:58:03 +0100
From: Frank Dittrich <frank_dittrich@...mail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New plugin load order magic
On 01/05/2013 10:52 AM, magnum wrote:
> On 5 Jan, 2013, at 2:34 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
>> When I change the Makefile again (use $(SORT) without -r), remove
>> john.o, and build a new john version without a make clean, I get a
>> binary of size of 2146816 bytes.
>> The dummy format test gives between 62825K and 64214K now, which is
>> somewhere between the c/s rates of the other binaries.
>>
>> Admittedly, dummy isn't the most important format.
>> But I don't understand these fairly reproducible c/s rate differences.
>> And I really don't know why the binaries differ in size.
>>
>> May be I should get some sleep and hope someone else can come up with an
>> explanation.
>
> Both issues are just effects of building slightly different things. The size difference is due to alignments.
Not really. When I use
$ make clean
before building the version with the reversed sort sequence, the binary
gets the same size as the one with the normal sort sequence.
Only if instead of a
$ make clean
I just remove those objects which should be affected by the different
sort order (../run/john, john.o, fmt_externs.h, fmt_registers.h),
the binary which results from the build differs in size.
> The speed difference, we have seen that before. Sometimes I have even made optmizations that I could "prove" (with valgrind) should speed things up, yet slowed things down. This may be because of bad luck with cache lines, and things like that.
You are probably right. But I dislike this unsatisfying degree of
predictability.
Frank
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.
