[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <18efd4f.5344.1393497e1d4.Webtop.0@cox.net>
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.
