Date: Fri, 17 May 2013 01:18:52 -0700 From: Myrice Li <qqlddg@...il.com> To: john-dev@...ts.openwall.com Subject: Re: password generation on GPU magnum, Sayantan - On Thu, May 16, 2013 at 5:09 AM, magnum <john.magnum@...hmail.com> wrote: > > > Oh, at first I misread what you wrote above. You're asking not whether > > to generate keys on host vs. GPU (the short answer to which is that we > > should do both of these things), but whether to do the GPU portion of > > key generation inside the format or with code shared between formats. > > So far, we only considered doing it from the same kernels that do the > > crypto, so we'd have duplicate implementations of the GPU side of mask > > mode (one for each fast hash format). I think that for mask mode this > > is in fact what we should be doing, and those duplicate implementations > > will end up having enough format-specific optimizations for the code > > "duplication" to be worth it. (Ditto for code responsible for comparing > > computed vs. loaded hashes, using bitmaps and such.) We may also have > > generic implementation(s) (or portions thereof), to be #include'd from > > multiple per-format OpenCL kernels. Using separate kernels (with > > communication via global memory?) is likely slower. > > > A kernel can call another kernel iirc so it might not be too bad. Maybe > try it out? It could simplify shared use. > > magnum > A kernel can call another kernel only with same configuration(thread/block number) before Kelper(sm_35 iirc). So it may not feasible to have this. But it is also depends on implantation. It is worth to have a try. Myrice 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.