Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 11 Mar 2015 21:09:20 +0300
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: Xeon Phi

Hi,

I??m a student from Peking University, China. And I??m very interested in that GSoC project.

What about merging ??JtR support for Xeon Phi?? and ??Better SIMD implementations of SHA-2?? into one project? Since they??re both related to the use of SIMD instructions.


Lei


> ?? 2015??3??6????????12:47??Solar Designer <solar@...nwall.com> ??????
> 
> Hi,
> 
> I've finally cleaned up and committed my Xeon Phi support patch for
> descrypt into the core tree, along with addition of the linux-mic make
> target.
> 
> The introduction of extra intrinsics is straightforward:
> 
> http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/john/john/src/DES_bs_b.c.diff?r1=1.42;r2=1.43
> 
> The speed is not so great, but we knew this before:
> 
> [user@...er-mic0 user]$ LD_LIBRARY_PATH=. ./john -te=1 -form=descrypt
> Will run 240 OpenMP threads
> Benchmarking: descrypt, traditional crypt(3) [512/512]... DONE
> Many salts:     80170K c/s real, 333233 c/s virtual
> Only one salt:  7660K c/s real, 61684 c/s virtual
> 
> (This is on our 5110P.)
> 
> The icc-generated assembly code for DES_bs_b.c looks sane to me (about
> as good as what we're used to seeing for AVX, or maybe even better since
> there are 32 ZMM registers).  I also experimented with adjusting
> DES_bs_cpt in DES_bs.h, and the previous default of 32 turned out to be
> nearly optimal so I left it intact.
> 
> magnum - please merge these changes into jumbo.  Thanks in advance.
> 
> This will provide a baseline for addition of MIC intrinsics to other
> parts of John the Ripper jumbo tree, which is a task we have listed
> among our ideas for this year's GSoC projects:
> 
> http://openwall.info/wiki/ideas#John-the-Ripper-support-for-Xeon-Phi
> 
> ... and perhaps this will need to be merged with another task, if done
> under GSoC, since at this time it feels like too little work for GSoC,
> or maybe the scope should be expanded in some other way - suggestions
> are welcome.
> 
> Alexander

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ