[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANJ2NMNZr3q+RkEM_Noq-8o8Rp4_hhTSpF-xx2r6+bcH-f8=fA@mail.gmail.com>
Date: Mon, 9 Jul 2012 11:18:00 +0800
From: myrice <qqlddg@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: About very high memory usage
On Mon, Jul 9, 2012 at 10:14 AM, Solar Designer <solar@...nwall.com> wrote:
> 42K c/s? Is that like a thousand times slower than normal, and a lot
> slower than a CPU as well? If so, that's not really usable. Maybe you
> have some loops that go until your max_keys_per_crypt regardless of the
> actual number of keys? If so, can you adjust those to go until the
> actual number without incurring much performance impact on supporting
> this variable count?
>
No, I have already reduced the actually number of keys. I make the
count in crypt_all() as actually number of keys crypted. I think GPU
cannot efficiently support small size especially the fast hash. I
think the "faster" the slower. The xsha512-cuda takes 58% time on GPU
and others on CPU. Take the raw-sha256-cuda as an example, I believe
it takes shorter time on GPU than xsha512-cuda, so the performance is
worse.
> Also, 200 MB for just a thousand of hashes (and salts) is still a lot,
> considering that it is reasonable to run John on millions of hashes at
> once (this is often being done).
>
> Maybe we need to declare single crack mode as unusable with many GPU
> formats, but supporting lower/variable keys_per_crypt is desirable
> anyway (e.g., if running with a small wordlist).
>
Now, one idea is reduce to min to 1 and use CPU for single mode. Or we
dynamically detect the key number, if it small than a size - with this
size, CPU is more efficient- we use CPU instead.
Thanks
myrice
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.
