[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130822200325.GA29078@openwall.com>
Date: Fri, 23 Aug 2013 00:03:25 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: *pcount type should be uint64_t
Sayantan -
On Thu, Aug 22, 2013 at 09:58:09PM +0200, magnum wrote:
> On 22 Aug, 2013, at 20:10 , Sayantan Datta <std2048@...il.com> wrote:
> > Since *pcount is updated inside crypt all, its value sometimes exceed unsigned int range producing wrong c/s result. Currently *pcount is int type which is clearly not sufficient.
> >
> > Since it is a core bug I think it is better if you deal with this otherwise I will try to fix this issue if you say so.
>
> Are you saying you may process more than 4G keys in a single call to crypt_all()? A kernel duration should be in the range of 100 ms, not seconds. Even using signed int and 2G keys my spontanteous reflection is that you should process fewer keys per kernel call. Or does that really hit performance?
>
> Having said that, I'm perfectly fine with changing to unsigned int for a starter.
I second magnum's comments on this. 2G+ keys per call sounds excessive
for current GPUs, in terms of kernel invocation duration. Perhaps it's
a side-effect of how you're doing things, and you need to avoid that?
You may calculate how large *pcount would be, and if it'd exceed a
certain threshold (which you'd keep below 2G), then reduce the portion
of mask processed on GPU until the would be *pcount value is sane.
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.
