Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 27 Jun 2013 19:23:44 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: latest version of descrypt project on reddit

On Wednesday 26 June 2013 07:13 PM, Sayantan Datta wrote:
> For single iteration its speed was:
>
> Run time: 0.114362 s
> Rate: 4694.471722 Mkeys/s
> Time to search keyspace: 177.655758 days
>
> So I modified the code a little bit to put it under 25 iteration. 
> Surprisingly the speed got reduced by 1/50 times instead of 1/25!! I'm 
> trying to figure out why?
>
> Run time: 4.571239 s
> Rate: 117.445372 Mkeys/s
> Time to search keyspace: 7101.173235 days

I profiled the kernel using codeXL.

When we have all 16 rounds unrolled put under single iteration , cache 
hit is +99%. This is supported by the evidence that there is 0% memory 
unit stalls and very little fetch from video memory.This corresponds to 
the first case(4694Mkeys/s).

Next when we put the 16 rounds of des in a 25 iter loop the cache hit 
suddenly drops to 1%.  Now the memory unit is stalled 23% of the time 
and video memory fetches are increased by nearly 100x.  This would be 
the second case(117 Mkeys/s).

We can increase the cache hit back to +90% with almost 0 memory unit 
stalls if we can somehow unroll only 4 rounds and put it under 
appropriate iteration count.(I tested using 100 to keep the amount of 
ALU work almost same as the previous case).

With 4 rounds unrolled and put under a 100 iteration loop.

Run time: 0.112433 s
Rate: 298.438078 Mkeys/s
Time to search keyspace: 2794.549328 days

Also I did some testing with non-hardcoded unroll of 4 rounds where the 
bitsliced keys are indirectedly accessed by GPRs. The result was similar 
to what we are currently getting in our des implementation.

Now under actual scenario we can't hardcode 4 rounds alone. Is there 
anything else we can do to increase the cache hit and reduce memory unit 
stalls?

Regards,
Sayantan

Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ