[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Sat, 24 Mar 2012 10:03:18 -0600
From: RB <aoz.syn@...il.com>
To: john-dev@...ts.openwall.com
Subject: bcrypt: actual performance versus benchmark
On Fri, Mar 23, 2012 at 18:54, Solar Designer <solar@...nwall.com> wrote:
>> It's not terribly common but is agonizingly
>> slow compared to pretty much all the rest of the algorithms, saving
>> perhaps RAR. :) Although my W3565 (soon to change) benches around 2k
>> c/s with 4 OMP threads, against a single hash I'm seeing at most 100
>> c/s. This makes even simple dictionary runs a practice in patience.
>
> Are you saying that benchmark gives you 2k c/s, but actual run only
> 100 c/s? Is that for bcrypt or for RAR? Anyway, this is best discussed
> on its own thread.
Yes, for hashes beginning with "$2$" harvested from a SuSE Enterprise
Linux system I was analyzing.
On my W3565, which shows best JtR performance with 4 threads
(OMP_NUM_THREADS=4), and using the magnum-jumbo git repo updated
2012/03/21, "./john --test=20 --format=bf" benchmarked at between 2k
and 2.1k c/s.
When cracking a single hash, actual speeds experienced were between 50
and 100 (occasionally reaching up to 110) c/s on a system with no
other load. This was on a system running gentoo-sources-3.3.0,
glibc-2.14.1, and gcc-4.6.2 (~x86_64 fully updated).
I confirmed this on an OS X 10.6 system with a 2635QM and the latest
XCode. The processors are roughly identical in performance otherwise
(PassBench actually puts the laptop at 63xx and the Xeon at 60xx for
their unidimensional benchmark), and their bf hash performance was
effectively identical.
I'm dumping all of this because I'm going 100% incommunicado for
several days and don't want to stifle discussion for lack of
information.
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.
