[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 23 Sep 2012 05:38:53 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: JtR 1.7.9-jumbo-7
On Sat, Sep 22, 2012 at 12:14:35AM +0000, donovan wrote:
> Thanks a lot this great news & build.
>
> I just compiled without touching anything on the "MakeFile",
Thanks. It's good to know that we've dealt with the build problems you
were experiencing in -jumbo-6.
> just for checking the GPU bench.
OK. Please note, though, that the specific two formats that you've
benchmarked (and some others) are currently implemented on GPU as part
of JtR development only, not intended for actual use yet. They work,
but are not significantly faster than their CPU equivalents, if at all.
JtR's GPU support is currently intended for actual use on slow hashes
(like mscash2, phpass, sha512crypt) and some non-hashes (like RAR), not
on fast hashes (like those two you benchmarked).
> Benchmarking: Raw MD5 [OpenCL (inefficient, development use only)].DONE
> Raw: 32896K c/s real, 108240K c/s virtual
...
> Benchmarking: MySQL 4.1 double-SHA-1 [OpenCL (inefficient, development
> use only)]... DONE
> Many salts: 18324K c/s real, 85792K c/s virtual
> Only one salt: 18324K c/s real, 85792K c/s virtual
As you can see, these honestly state they're "inefficient, development
use only", to set the expectations about their poor performance.
> To compared with the last build of Erik Winkler ( the one i use actualy).
>
> new-host:run xxx$ ./john --format=raw-md5 --test
> Benchmarking: Raw MD5 [128/128 SSE2 intrinsics 12x]... DONE
> Raw: 29296K c/s real, 29296K c/s virtual
>
> new-host:run xxxx$ ./john --format=mysql-sha1 --test
> Benchmarking: MySQL 4.1 double-SHA-1 [128/128 SSE2 intrinsics 8x].DONE
> Raw: 8237K c/s real, 8237K c/s virtual
OK, you do achieve a 2x speedup at MySQL 4.1 double-SHA-1, which is
nice. However, you'd achieve greater speedup (4x or more) by running it
with MPI on CPU.
That said, thank you once again for testing this build. Such
preliminary testing is a reason why we keep those inefficient GPU
formats in the tree. And, more importantly, you've tested the GPU build
as a whole, including compiling C code for other formats that are
actually reasonably efficient (although you did not test
compiling/running their OpenCL kernels - you could).
Alexander
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.
