[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 28 Mar 2012 04:40:32 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: rawsha256.cu patch(using shared memory)
Lukas -
Thank you for your help with the discussions around GSoC.
On Tue, Mar 27, 2012 at 05:51:40PM +0200, Lukas Odzioba wrote:
> I should have somewhere old version much faster than that.
Oh, old version. This explains the faster benchmarks on the wiki.
Why don't you get that faster version into magnum-jumbo, then? Does the
new version have some other advantage?
> Attacking worst optimized format is not a good idea if you want show
> your abilities.
I guess myrice was not aware that this was considered the worst
optimized format, and going after a low hanging fruit makes sense in
many cases (maybe not to show one's abilities, though).
> First of all you must decide will you apply for slow, or fast hashes.
> Those are DIFFERENT tasks with different needs.
Yes, but I'm fine with people trying both briefly to get a better
feeling of that. ;-) Otherwise they won't make an informed decision on
what to apply for.
> Please do not post multiple results for the same format, choose top1
> or avg if you want.
BTW, the relbench script may be used to compare two sets of results
(with multiple invocations of each version of the program):
http://www.openwall.com/lists/john-dev/2011/12/14/1
(this demonstrates it for an OpenMP setting, but the same approach can
be applied to different source code revisions and CUDA/OpenCL).
For these highly unoptimized formats, we're looking for such major
differences in speed that this fine benchmarking is not necessary,
though. So raw output should better be posted.
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.
