Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 20 Feb 2015 02:36:03 +0530
From: Sayantan Datta <std2048@...il.com>
To: john-dev <john-dev@...ts.openwall.com>
Subject: Re: descrypt speed

On Fri, Feb 20, 2015 at 12:34 AM, magnum <john.magnum@...hmail.com> wrote:

> I did some testing on a GTX980 using (1,1). Tried it with the good old
> Gawker dataset, with 3844 salts. After all kernels were compiled (yeah
> that took a while) and running full speed, virtual memory footprint was
> 38.5 GB(!) but resident size was just 2.19 GB which is pretty sane.
>

OMG 38.5 GB!! According to Royce, binary size is around 300KB, so the
expected memory footprint should be around 300KB x 3844 = 1.1GB. Maybe this
means unlike AMD, the binaries does not contain the ISA, which probably is
built from the binaries and is much larger than 300KB. Did you try running
it the second time? Was the compilation any quicker, assuming the binaries
weren't deleted ? Also what speeds are you getting with multiple-salts ?


> I
> immediately found a bad bug (segfault after cracking a binary with a
> non-unique salt) which is now fixed (df95184a).
>

Thank you. Although I did some testing with the test-suite hashes in
DES_tst.in, but it didn't trigger that error.


>
> I also did some changes to ensure proper Makefile dependencies for
> opencl_DES_hst_dev_shared.h, so you can now edit that file and be sure a
> simple "make" really rebuilds all files involved.
>

Thank You again. We could do the switching at runtime, but prior to that we
need to test devices which can really benefit form (1,1) kernel.

Regards,
Sayantan

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.