[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+TsHUDzGhZ_jpf-vmYKUgo2LTSnUy-fzbvQdAV5rz=QrBYwEA@mail.gmail.com>
Date: Mon, 7 Jan 2013 14:51:04 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: des-opencl
>
> Hi Alexander,
On Mon, Jan 7, 2013 at 9:01 AM, Solar Designer <solar@...nwall.com> wrote:
> Another curious detail about mysterymath's implementation is that it
> obviously exceeds instruction cache, yet is reasonably fast on GCN.
> We should try that too as it avoids pointer indirection and reduces
> register pressure due to hard-coding key bit indices (no key schedule
> array needed anymore). Lukas reported very poor performance on 5850,
> though.
>
Yes I tried that too, but speed was far worse due to hardcoding. Although I
tried this by hard-coding only k=0 and k=96 , there was a huge performance
drop, probably due iCache overrun. To fully hard-code the kernel we need to
do that for k=0 to 720 with a gap of 48 which should be around 16 times
more code(instructions) than we currently have in the kernel.
The speed seen during actual cracking is a lot lower - about 1M c/s,
> not 44M c/s as --test would suggest (this is for many salts). Why is
> that? How to avoid this problem?
If you check the speed just after it starts, it should be quite low. It
should increase rapidly after the compilation of all kernels with different
salt is finished. In fact I didn't had much free time lately to fully
implement the binary patch. Hopefully I would be able to complete it in a
week or two.
Regards,
Sayantan
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.
