Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 17 Aug 2012 08:38:52 -0400 (EDT)
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.


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.