[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4a5cad6559ff3488a5a7b8f3b85de93d@smtp.hushmail.com>
Date: Mon, 18 Jun 2012 02:51:15 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: Reduced binary size
On 2012-06-17 22:54, magnum wrote:
> On 2012-06-17 01:22, magnum wrote:
>> Also, unlike the formats that use intrinsics.c, this format will benefit
>> from a reduced binary_size (just the one 32-bit int that is checked in
>> cmp_all()), and a "linkedin" version of that would probably perform way
>> better than our current one, with six million hashes. This would be
>> trivial. Maybe I'll try it out later unless someone else do.
>
> No, wait... What is stopping us from using reduced binary size in the
> old formats too? Nothing! I have been confused for years. Maybe I should
> try this out in raw-md5 and raw-sha1[_li] and see what happens when
> loading zillions of hashes.
I just committed reduced binary size for raw-md4/md5/sha1 and nt2. Saves
3 or 4 bytes per loaded hash (makes some difference for 135 million
hashes, lol) and should help keeping good stuff in cache. It's not
merged to bleeding yet - the get_source() gets a little trickier and I
should get some sleep.
It passes Test Suite - actually I would have committed a hideous bug in
SHA-1 if it wasn't for TS.
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.
