[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150425173937.GB21111@openwall.com>
Date: Sat, 25 Apr 2015 20:39:38 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] JtR SIMD support enhancements
Lei,
On Sat, Apr 25, 2015 at 10:18:21PM +0800, Lei Zhang wrote:
> On Apr 25, 2015, at 8:46 PM, Solar Designer <solar@...nwall.com> wrote:
> > So, any idea about the weird speed you got for bcrypt here? Here's
> > mine: maybe max_keys_per_crypt is set based on the host's number of
> > threads, so is too low for MIC?
>
> I think you're right. There's a call to omp_get_num_threads() to determine max_keys_per_crypt. I wrap it with "#pragma offload ..." and the performance becomes:
> -----------------------------------------------------
> [zhanglei@...ter src]$ ../run/john --test --format=bcrypt
> Will run 12 OpenMP threads
> Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/64 X2]... DONE
> Raw: 5888 c/s real, 5888 c/s virtual
> -----------------------------------------------------
Looks reasonable now. Just a bit slower than expected:
5888/6339 = 93%
236/240 = 98%
Is the overhead of offloading so high that we have a 5% performance hit
even at these low c/s rates? I guess the initial S-boxes get
transferred from host every time? That's 4 KB times max_keys_per_crypt
(or rather times "count", which is usually same). It's a bit nasty, yet
the 5% performance hit feels too high.
Do you have access to any machines with more than one MIC card, to see
how offload would behave there?
Anyway, did you commit this code to some branch? Non-default, I guess,
since it's highly experimental and mostly breaks things? We should
preserve it somewhere for future experiments.
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.
