[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 17 Apr 2012 20:34:45 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Weekly report 1
myrice -
Thank you for starting with the weekly reports early. This is very nice.
Since we're going to ask other students working on JtR to post weekly
reports in here as well, please include your nickname in the Subjects of
further weekly reports so that it is more obvious which report any
replies refer to.
On Tue, Apr 17, 2012 at 03:10:07PM +0800, myrice wrote:
> Last week, my accomplishments are:
>
> 1. For correctness, implemented cmp_exact for xsha512-cuda
> 2. Reversed last 3 rounds of sha512 in xsha512
> 3. Implemented unoptimized xsha512-opencl
Great.
> 4. Tried async cpy on GPU but no performance gains, still keep tuning.
IIRC, what you tried was not supposed to result in any speedup because
your GPU code was invoked and required the data to be already available
right after you started the async copy - so you had it waiting for data
right at that point anyway.
Lukas' code was different: IIRC, he split the buffered candidate
passwords in three smaller chunks, where two of the three may in fact be
transferred to the GPU asynchronously while the previous chunk is being
processed. You may implement that too, and I suggest that you make the
number of chunks to use configurable and try values larger than 3 (e.g.,
10 might be reasonable - letting you hide the latency for 9 out of 10
transfers while hopefully not exceeding the size of a CPU data cache).
> In the next week, my priorities are:
>
> 1. Optimize sha512 stuff in xsha512
> For one round sha512, ctx can be replaced by a string. Merge init,
> update, final in one function
OK. I think the compiler does something very much like this already,
but doing it manually may allow for further optimizations, so we should
do it.
> 2. Merge cmp_all() with crypt_all()
> For crypt_all(), we just return. In cmp_all(), we invoke GPU and return
> a value indicate if there is a matched hash.
This is going to be problematic. It will only work well for the special
case (albeit most common) of exactly one hash per salt. When there are
a few more hashes per salt, cmp_all() is called multiple times, so you
will once again have increased CPU/GPU interaction overhead. When there
are many more hashes per salt, cmp_all() is not called at all, but
instead a get_hash*() function is called.
This is why I suggested caching of loaded hashes in previous calls to
cmp_all(), such that you can move the comparisons into crypt_all()
starting with the second call to that function. Then your GPU code for
crypt_all() will return a flag telling your CPU code for cmp_all() to
just return that fixed value instead of invoking any GPU code.
> 3. Keep optimizing xsha512-opencl
OK.
> 4. Discussing password generation, maybe not implement this in next week.
Yes. Definitely don't implement it that soon - we need to discuss first.
Thanks again,
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.
