[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <68c6ec0a6539d85d49a091959eff9336@smtp.hushmail.com>
Date: Thu, 05 Jul 2012 17:04:25 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: common find_best_workgroup()
On 2012-07-05 16:50, Claudio André wrote:
> I can change mine too. I need only two "new" things inside the
> default find_best stuff.
>
> I will comment on one of your commits, just have to check if it
> makes sense on AMD first.
Please do. I'm still experimenting.
> We have been getting different results using "find_best" functions.
> It is something i really enjoy to use (on new hardware AND on
> experimentation).
I think find_best_workgroup is mostly good only for developers,
evaluating a fixed size (possibly depending on CPU vs GPU and perhaps
AMD vs Nvidia) that is then normally used.
> However, i agree that it is becoming clear it is not really
> necessary. I mean, the max possible value is always a good choice.
I believe the max possible is often the worst choice, at least for slow
and/or complicated hashes (like RAR). Also, the lower keys-per-crypt we
can do (at same c/s) the better.
Besides, most CUDA formats are faster than OpenCL, even with non-optimal
fixed values, and their start-up time is minuscule compared to OpenCL.
I'm pretty sure it's not as simple as "CUDA is faster than OpenCL" anymore.
magnum
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.
