[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 11 Apr 2015 17:54:14 +0300
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: [GSoC] John the Ripper support for PHC finalists
On Sat, Apr 11, 2015 at 01:16:10PM +0200, Frank Dittrich wrote:
> On 04/11/2015 01:18 AM, Agnieszka Bielec wrote:
> > 2015-04-09 6:21 GMT+02:00 Solar Designer <solar@...nwall.com>:
> >> I suggest that you leave OpenCL alone for a moment (well, maybe right
> >> after you finish whatever you're currently doing to it), and instead get
> >> POMELO's SIMD code into the tree first. Both SSE* and AVX2, please.
> >
> > I've added SSE2 and isn't faster (bleeding-jumbo)
>
> May be it is a good idea to look how other formats where converted from
> a simple implementation into a tuned implementation.
Yes, but POMELO is somewhat different than most of those: it readily
comes with SSE2/AVX and AVX2 code. We may consider bringing in extra
instruction-level parallelism from interleaving 2+ instances, though.
Agnieszka has since reported that the SSE2 code is slightly faster.
This might be fine. The benchmarks for POMELO so far (not in JtR)
suggest that it's less than 2x faster with its SIMD-enabled code than
without. Indeed, we'll need to look into this more closely, and
identify reasons why SIMD does not speed it up more.
> Since we don't have a tutorial or a how-to guide for this, I think the
> best way to figure out what needs to be done is to look at specific
> commits of a format that has recently been added.
> I think the best candidate is the sapH format, since it has been added
> recently, so that there aren't too many commits which are unrelated to
> tuning the format.
>
> $ git log sapH_fmt_plug.c
>
> just shows 16 commits in bleeding jumbo.
>
> Those commits related to JtR refactoring are quite easy to distinguish
> from commits that actually tune the format.
Thanks. Something like this could be relevant for Parallel, but that's
about it. The rest of PHC finalists are substantially different from
what we have in typical JtR formats. They are a closer match to scrypt,
but we don't currently have interleaving for scrypt (we do have 128-bit
SIMD for it within one instance).
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.
