|
Message-ID: <CADkMHCkT_nxzkEhhnWH9rwzh-_cvqicTrcSrkoBpB3SuGFdp0w@mail.gmail.com> 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.