Date: Wed, 4 Jan 2006 23:13:24 +0300 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: 64bit support on windows? On Wed, Jan 04, 2006 at 03:40:22PM +0000, Phantom wrote: > I recently acquired an AMD64 bit CPU and was wondering why there is no makefile > option for 64bit under windows? (using x86-64.h ..??) That's for several reasons: 1. I am not using Windows myself; it is tricky enough for me to go to a Windows box just to do plain Win32 builds of John right now. (FWIW, I tried to install Cygwin on ReactOS running under QEMU running under Openwall GNU/*/Linux, but that failed in the middle of the installation process. I suspect that it might work with a future version of ReactOS eventually.) 2. I do not know whether there's Cygwin for Win64 already (is there?) > And, if made, would it require Win64 for it to run? Yes. > And.... is there any significant performance increase in running the 64bit > linux build over the default cygwin-mmx one? if so, how much? This gives us a third reason to not hurry to support 64-bit Windows: 3. No. MMX was essentially 64-bit already as far as this application is concerned. The availability of 16 general-purpose registers with x86-64 (as opposed to just 8 with x86/MMX) may provide perhaps a 20% improvement at bitslice DES, but on the other hand the MMX code is hand-optimized, whereas the x86-64 code is currently being generated by a C compiler. The benchmarks done on Linux systems so far show that the hand-optimized MMX code provides almost the same performance that the compiler-generated x86-64 code does. On the particular benchmark results I have in my collection (for an Opteron CPU), the following hash types performed better when built for 32-bit x86 with MMX: Traditional DES, BSDI DES, FreeBSD MD5, OpenBSD Blowfish. The following hash types performed better when built for x86-64 natively: Kerberos AFS DES, NT LM DES. But the differences in performance were within 20% for most hash types, with the rarely-used Kerberos AFS DES being the only exception. The results may differ for other CPUs and other C compilers (or gcc versions). To answer your next question: no, I am not planning to develop hand-optimized x86-64 assembly routines for John, at least not any time soon. 20% is not enough of a performance win to justify that work for me right now. (The performance improvement with assembly code was _much_ bigger for x86/MMX since the architecture was register-starved and since MMX was not available for use by a C compiler. x86-64 is rather good, so C compilers manage to do a good job, too.) What I _might_ do at a later stage, though, is produce some hybrid x86-64+MMX and/or x86-64+SSE code for a bigger performance win. -- Alexander Peslyak <solar at openwall.com> GPG key ID: B35D3598 fp: 6429 0D7E F130 C13E C929 6447 73C3 A290 B35D 3598 http://www.openwall.com - bringing security into open computing environments Was I helpful? Please give your feedback here: http://rate.affero.net/solar
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.