Initially, this page will be the place to collect and share trivial john –test benchmarks on different systems. At a later time, it may make sense to turn it into a namespace with sub-pages for john –test benchmarks (only c/s rate matters) and actual cracking runs (lots of things matter). Also, the underlying data may be uploaded/collected (e.g., exact john –test outputs, /proc/cpuinfo off of Linux systems, john.log files).

Please add your benchmark results to the tables below as appropriate. Please make sure to run the benchmarks on an otherwise idle system. For OpenMP-enabled benchmarks, pick the “real” c/s rate. For single CPU core benchmarks, the “real” and “virtual” time results should be almost the same (as long as the system is indeed otherwise idle), so it should not matter which one of these two you pick.

Please keep these tables sorted by performance at DES-based crypt() for “many salts”, better results listed first, best results for each hash type shown in bold, best results for CPUs operating at their rated frequencies (non-overclocked) and running non-modified JtR code shown in bold-italics (only used when these are not the absolute best results).

For multi-CPU systems and multi-core CPUs, the c/s rates given are for one CPU core. For example, the Q6700 CPU achieves an equivalent of just over 2.5 million of traditional DES-based crypt(3) checks per second per core, but since this CPU is quad-core, this translates to just over 10 million of checks per second per CPU chip, with proper parallelization.

For some CPUs (such as Core i7), the per-core clock rate varies with the number of cores in use, so directly multiplying the per-core c/s rate by the number of cores would not yield the CPU's combined c/s rate capability (the actual combined c/s rate would be less), but on the other hand if the CPU also supports SMT (Hyperthreading) then additional speedup may be obtained by running more JtR processes than the CPU's number of cores.

Please note that for 32-bit x86 targets (those with x86-any, x86-mmx, and x86-sse2 in their names), the C compiler and its version are largely irrelevant, because almost all of the performance-critical code is written in assembly language anyway. The above table specifies the compiler and version in all cases, but for these targets there's no need to submit multiple almost identical results that differ only in compiler choice and/or version.

For x86-64 targets there should be almost no performance difference across compilers/versions for DES-based crypt(3) hashes, for the same reason. However, other hash types may actually be affected by C compiler and its version, so multiple entries may be submitted.

Windows LanMan hashes are so very fast that their performance is significantly affected by various types of overhead, and you should not be surprised if performance changes by as much as 10% or even more between JtR builds and even between invocations (e.g., because of different code placement in caches), even though JtR tries to mitigate this effect to some extent. Thus, benchmarks that differ from existing ones for the same CPU and clock rate only at LanMan hashes are generally of little value, unless the difference is well over 10% and/or it is for a specific (known) reason (such as a relevant code change between JtR versions).

With few exceptions, the operating system should not significantly affect JtR performance, however it affects what JtR versions and make targets you may use and what compilers and versions are available. Hence, it makes sense to list it and also to include benchmarks on the same hardware, but with different operating systems (and thus with different make targets). Luckily, there are not as many different operating systems as there are different gcc versions. Multiple benchmarks for different versions of the same operating system flavor, with everything else staying the same as well, should not be listed. If desired, for clarity, listings with obsolete operating system versions may be replaced with those for currently maintained ones.

That said, if in doubt whether your benchmark results are of value, please do submit them, and please do not be offended if they are moved to another table or sub-page meant to hold likely insignificant results (yet to be created, if the need arises).

If you feel that a benchmark result is insignificant (given the criteria above) or incorrect, please move it into another table (create one) and indicate the reason for your decision in the “edit summary” for your change to this wiki page.

Thank you!

Back to John the Ripper user community resources.