[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 5 May 2015 15:58:10 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: Lei's weekly report #1
Lei,
On Tue, May 05, 2015 at 08:06:35PM +0800, Lei Zhang wrote:
> - Find out more formats where OMP_NUM_THREADS isn't optimal for MIC,
OK.
> and adjust it accordingly.
No, please don't waste time on this! There are very few exceptions
where this may be actually needed, and not now.
You should in fact experiment with lower OMP_NUM_THREADS, but only as a
way to provide you extra hints on what formats need further optimization
and roughly what kind. This isn't to choose optimal values for actual
use, at least not yet. With proper code, 240 (or 236 for offload)
should be optimal in almost all cases. Right now, this applies to "slow
hashes" only (phpass is a slow enough one, so to it too).
For fast hashes (with speeds currently in the millions, whereas they are
supposed to reach a billion c/s), we know that our current OpenMP
parallelization is very inefficient. You would in fact see better
speeds with fewer threads there. In fact, with a lot fewer (way below
60, so clearly under-using the device). But this isn't helpful.
We know we should be using --fork and not OpenMP for those formats at
this time. And we may introduce a different approach at OpenMP
parallelization later (if you like, you may be involved in this later).
Thanks,
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.
