[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2b7e7735151572ded70402d617051785@smtp.hushmail.com>
Date: Sun, 6 Jan 2013 02:38:07 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New plugin load order magic
On 5 Jan, 2013, at 11:58 , Frank Dittrich <frank_dittrich@...mail.com> wrote:
> 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.
I really appreciate your testing, but this is a fairly weird report and I can't think of any other response than just ignore it. What conclusion should I draw from this? What conclusion do you draw yourself?
>> 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.
I do too, really, but from benchmarking dummy 10 times in a row with any build I usually get that variation in speed. This is frustrating and I have spent some time in the past trying to mitigate it. Some other formats produce the same speed, down to the last digit, every time. I have absolutely no idea why!
My punch line is that I presume your observations are correct - but they are not really results of the changes to the plugin magic.
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.
