[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABob6irTqt47LNZtZLTF7Jcu-pu_30DvHEerb+18a-e-hiE8NA@mail.gmail.com>
Date: Tue, 9 Jun 2015 21:19:15 +0200
From: Lukas Odzioba <lukas.odzioba@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: PHC: Lyra2 on CPU
2015-06-01 23:57 GMT+02:00 Agnieszka Bielec <bielecagnieszka8@...il.com>:
> I implemented omp in Lyra2 in 3 different ways and I am including tests below
>
> a) I used nested omp
> b) I am using omp only in crypt_all() function and one hash is
> computed by nPARALLEL number of threads
> c) I am using omp only in crypt_all() function and one hash is
> computed by only one thread
In my opinion c) is the most obvious way to go in case of JtR.
b) might have some special usages, two of them I can think of is where
it will be actually faster than c) for any reasonable set of
parameters or it will be somehow faster use it in single hash attacks.
So I would focus on optimization of c-version and some
experiments/thoughts which can prove/disprove that implementing
b-version makes sense at all.
> -we are using memory nPARALLEL times as many as in method b)
I still did not read though full lyra2 pdf, can you explain to me why
using less threads leads to increasing memory consumption.
If it is true then can't we simulate context switching ourself, and
will it help to solve memory consumption drawback?
Lukas
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.
