[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Jul 2012 07:28:19 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: About very high memory usage
On Mon, Jul 09, 2012 at 11:18:00AM +0800, myrice wrote:
> 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.
Sure.
> 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.
I think that's not quite it. Sure efficiency is worse with faster
hashes, but the c/s rate shouldn't be worse. I think there's something
else going on with raw-sha256-cuda - that is, it should be possible to
bring it to the same c/s rate that you achieved for raw SHA-512, within
the current formats interface.
> > 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.
Sure, but this complicates the code and may be confusing for users.
It might be better to refuse to run single crack mode on GPU except in
some cases where it's known to be OK and except when forced (e.g. add a
--force option for things like that).
Alexander
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.
