[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 12 Mar 2015 09:51:10 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] building JtR for MIC
Hi Alexander,
I’ll send a pull request later, with all the changes I made to get jumbo built on MIC.
As for those libraries, I think it’s a good idea to have them pre-built. Building GMP and Zlib for MIC is quite straightforward, but building OpenSSL requires some effort. I had to modify OpenSSL’s build system to get it built on MIC. And currently I’m only able to get through with version 1.0.0q, while the latest version is 1.0.2. I’ll try to describe the HOWTO in a README file.
As for the performance, I think you’re right that some other program might be running in the meantime. Currently one of my lab colleagues is using the MIC machine. I’ll check the benchmark when the machine becomes idle and report it back here later.
Regards,
Lei
> On Mar 12, 2015, at 1:56 AM, Solar Designer <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
>
> 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
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.
