[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <ABBD8B45-D7E8-4A4D-9D21-DF627CF18DBB@gmail.com>
Date: Sat, 14 Mar 2015 22:59:46 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] building JtR for MIC
Hi,
This time I got exclusive use of our MIC card and ran john-jumbo's benchmark again.
Here's the result:
----------------------------------------------------------
Will run 240 OpenMP threads
Benchmarking: descrypt, traditional crypt(3) [DES 64/64]... (240xOMP) DONE
Many salts: 11702K c/s real, 48709 c/s virtual
Only one salt: 4253K c/s real, 17728 c/s virtual
Benchmarking: bsdicrypt, BSDI crypt(3) ("_J9..", 725 iterations) [DES 64/64]... (240xOMP) DONE
Many salts: 572235 c/s real, 2363 c/s virtual
Only one salt: 206769 c/s real, 860 c/s virtual
Benchmarking: md5crypt, crypt(3) $1$ [MD5 32/64 X2]... (240xOMP) DONE
Raw: 128000 c/s real, 533 c/s virtual
Benchmarking: bcrypt ("$2a$05", 32 iterations) [Blowfish 32/64 X2]... (240xOMP) DONE
Speed for cost 1 (iteration count) of 32
Raw: 5942 c/s real, 24.8 c/s virtual
Benchmarking: scrypt (16384, 8, 1) [Salsa20/8 32/64]... (240xOMP) Killed
------------------------------------------------------------
It's better than last time. But descrypt is still too slow and scrypt is still crashing.
I checked the status of the MIC card, and found the free memory space left is no more than 3GB. This is reasonable since MIC has no external disk and the filesystem resides entirely on it's RAM. I think Solar is right that scrypt ran out of memory on MIC. MIC's memory is relatively small compared to the number of hardware threads it supports. And that's partly why multithread program written for traditional multicore processors cannot be smoothly ported to MIC.
As for descrypt, I don't know why it's so slow. It's supposed to share the same code as john-core, right? Or maybe there's something wrong with configuration. I'm still checking.
Lei
> On Mar 12, 2015, at 1:56 AM, Solar Designer <solar@...nwall.com <mailto:solar@...nwall.com>> wrote:
>
> On Thu, Mar 12, 2015 at 12:41:15AM +0800, Lei Zhang wrote:
>> I'm finally able to build john-jumbo for MIC. It can run on MIC now, but still has some problem. I'll describe the building process first, and then how it runs.
>
> Great!
>
> Could you please post patches or make a pull request on GitHub
> corresponding to your changes to get jumbo to build and work on MIC?
>
>> When I started building, I found there're some libraries that are required by john-jumbo but not natively available on MIC. They are OpenSSL, GMP and Zlib. I had to download and build them for MIC manually, which also took me a while.
>
> I think we'll need to have this described in a README-MIC file or/and
> have it scripted.
>
> We may also distribute a tarball with jumbo and these libraries
> pre-built for MIC.
>
>> With all library dependencies resolved, there're still some source files that failed to compile.
>
> Please share with us your patches to get these to compile.
>
>> Will run 240 OpenMP threads
>> Benchmarking: descrypt, traditional crypt(3) [512/512]... (240xOMP) DONE
>> Many salts: 3744K c/s real, 30881 c/s virtual
>
> This is 20x+ slower than the performance I reported here:
>
> http://www.openwall.com/lists/john-dev/2015/03/05/2 <http://www.openwall.com/lists/john-dev/2015/03/05/2>
>
> Your other benchmark results are also slower than they should be, but
> not by that much.
>
> Are you using this MIC card exclusively, or is it running some other
> code at the same time?
>
> You need to figure out this unexpected slowness. It might be related to
> other issues you'd be running into, such as the one with scrypt:
>
>> Benchmarking: scrypt (16384, 8, 1) [Salsa20/8 32/64]... (240xOMP) Killed
>> -------------------------------------------------------------------------
>>
>>
>> It seems the process got killed when running ???scrypt???. I'm still looking for the cause of this problem.
>> Suggestions are welcome.
>
> scrypt is special in that it needs much memory. Our test vectors appear
> to require up to 16 MB. For 240 threads, that's just below 4 GB. Since
> your 5110P has 8 GB RAM, it should probably successfully run this test,
> but maybe much of its RAM is occupied by something else? e.g. some large
> files uploaded to its RAM filesystem, or someone using it concurrently?
>
> The "Killed" diagnostic is consistent with the out-of-memory theory.
> The MIC card's Linux kernel's OOM killer was likely triggered.
>
> Alexander
Content of type "text/html" skipped
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.
