Date: Fri, 17 Aug 2012 08:38:52 -0400 (EDT) From: jfoug@....net To: john-dev@...ts.openwall.com Subject: Re: RAR early reject Is this new quick check logic, better done on cpu, and then only candates that fail to be elinated, get worked on in the GPU? We do get into the 'sparse' candidate issues (finding them, then processing, then accumulating final results), like I did with sunmd5, and the coin flip. But if you had enough candidates loaded, and the quick out was 1000x faster, then you could keep the CPU working, looking for quick outs, while GPU code was ONLY hammering away on the more complex, longer to perform, task on candidates that were not quick out. For pkzip, we had the 'checksum' that eliminated a WHOLE lot. I do not remember what the quick check elimiated, but I think it was about 90% or more. With a 2 byte checksum, it was pretty rare for pkzip to do a FULL test at all. Jim. On Fri, Aug 17, 2012 at 7:26 AM, magnum wrote: > On 2012-08-17 09:19, Milen Rangelov wrote: > > I'm thinking I won't gain too much from doing more on GPU. My priority > now (apart from more GPU speed) is splitting workload so each kernel > run > is 200 ms or so. Another possibility is firing off one batch on GPU > and > while that is running, compare the last and prepare the next. > > magnum
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.