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.