[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUAj9epeX9w22k53NOhbi3OOZOq=n+CGkEewN0WnwM0Ukg@mail.gmail.com>
Date: Mon, 9 Sep 2013 19:34:58 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: mask mode bug
On Sun, Sep 8, 2013 at 10:48 PM, magnum <john.magnum@...hmail.com> wrote:
> On 8 sep 2013, at 18:45, magnum <john.magnum@...hmail.com> wrote:
> >> With GWS=65536, memory usage reduces to "740MB" - still too much for
> >> cracking of one hash, but is more reasonable. Unfortunately, the speed
> >> is worse:
> >>
> >> 0g 0:00:03:04 0g/s 1976Kp/s 1342Mc/s 1342MC/s aaabetnqcu..aaabetpmpb
> >
> > The key buffer should be 640KB (n.b. not MB) in this case.
>
> That's not correct, it's about 3.5 MB allocated - but we only transfer
> 640KB at a key length of 10.
>
I'll look into this issues.
>
> > Considering we only have a single hash, I wonder what is using hundreds
> of megabytes of memory?
>
> Apparently it always allocates bitmap structs for 32 million hashes
> regardless of actual number loaded. And it allocates some kind of hash
> table with a fixed size of 512 MB. I presume this will be dynamically
> allocated later.
I'm statically allocating memory because it saves a lot of kernel arguments
(by putting them in a single structure) which in turn saves lot of vgprs.
When number of kernel arguments exceeds certain limit, it starts using
vgprs. I have verified this with catalyst 13,4. This may be a compiler
problem and if this problem is resolved in future then we wouldn't have any
problem with dynamic allocation.
Regards,
Sayantan
Content of type "text/html" skipped
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.
