Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150622181414.GA17407@openwall.com>
Date: Mon, 22 Jun 2015 21:14:14 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: tuning OMP_SCALE on MIC (was: Lei's weekly report #7)

Lei,

On Mon, Jun 22, 2015 at 08:44:29PM +0300, Solar Designer wrote:
> On Mon, Jun 22, 2015 at 10:12:16PM +0800, Lei Zhang wrote:
> > I ran through all self-tests on MIC with OMP_NUM_THREADS=240 and OMP_NUM_THREADS=60 respectively, and compared the results to find out which formats perform better with fewer threads. 
> > 
> > There're 309 formats in total (excluding dominosec8, which segfaults on MIC for the moment), and 125 of them run faster with OMP_NUM_THREADS=60. I may need to further tune OMP_SCALEs in those formats. I'll investigate that later.
> > 
> > The list of those formats is attached.
> 
> Thanks!  For most of them, we're simply aware that our current approach
> at parallelizing them is extremely inefficient.  They are too fast for
> it.  So tuning of OMP_SCALE is primarily needed for a subset of them -
> the slow ones, where good efficiency can be achieved despite of the
> current approach at parallelization.  Thus, please sort them by c/s rate
> obtained when running 1 thread (either a non-OpenMP build or with
> OMP_NUM_THREADS=1), in absolute terms, and start tuning OMP_SCALE
> (obviously in an OpenMP-enabled build and running 240 threads this time)
> with the slowest format.  Then proceed to the faster ones.

In fact, the sorting and tuning I described above should eventually be
applied to all formats, not just the 125 where non-optimal behavior is
seen via the OMP_NUM_THREADS 60 vs. 240 test.  This test detects not
only non-optimal choice of OMP_SCALE, but also hashes that are simply
too fast for efficient OpenMP scaling (like LM, which doesn't scale
beyond just a few threads with our current approach).  In fact, most of
those you identified are probably in the "too fast to scale" category.

So I suggest that once you've taken care of those of the 125 formats
where single-thread speeds are below 1M c/s, you switch to doing the
same for the slower ones of the remaining formats (not in the 125),
skipping those with > 1M c/s single-thread speeds.

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.