[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4ED2E2E9.7010103@hushmail.com>
Date: Mon, 28 Nov 2011 02:24:57 +0100
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: .bss size in -jumbo
2011-11-28 02:07, Solar Designer wrote:
> .bss in 1.7.8-jumbo-8 grew to 140 MB in a 64-bit build with OpenMP:
...
> I think at least top 5 of these (or maybe 7 or 9) should be changed to
> allocate their memory dynamically, like 1.7.9 does in MD5_fmt.c and
> BSDI_fmt.c. (1.7.9's DES_fmt.c and c3_fmt.c also use dynamic memory
> allocation, but in format-specific ways. BF_fmt.c's saved_key[] is
> relatively small (the number of buffered keys is low because this hash
> is so slow), and BF_std.c puts its larger data structures on thread
> stacks (just one instance per thread).)
Yes, this was already something I was planning to have a look at, sooner
or later. I really liked the "trick" you used in MD5_fmt.c:
static char (*saved_key)[PLAINTEXT_LENGTH + 1];
...
saved_key = mem_alloc_tiny(
sizeof(*saved_key) * fmt_MD5.params.max_keys_per_crypt,
MEM_ALIGN_CACHE);
It took me half a day to understand why it works. It's a very convenient
way of writing it!
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.
