Date: Sat, 12 Sep 2009 22:12:20 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: distro patches Speaking of Gentoo's johntheripper-184.108.40.206-r1.ebuild: On Thu, Sep 10, 2009 at 05:47:36AM -0600, RB wrote: > It's called in the src_test stage that is turned off by default, OK, so my guess was correct. > and is actually bypassed if there aren't existing system-wide > configuration files present from another installation. That's very dirty. Besides, it relied on "./john --test" returning a non-zero exit code on any failed test, which was not the case until my very recent changes for 220.127.116.11. While at it, I noticed that the ebuild uses "-fPIC -fPIE". This is probably part of a Gentoo policy, but the performance hit is hardly desirable for John the Ripper. Obviously, you need to benchmark it for a make target and hash type where CFLAGS actually matter. You won't notice a difference for most officially supported hash types on 32-bit x86 builds (due to the assembly code), but you should notice it for some other hash types and other make targets. In fact, even on 32-bit x86 builds LM hashes may be affected somewhat (6.5% on my test build). Then, do Gentoo's CFLAGS include -fomit-frame-pointer? Probably not. That's a further performance hit where it matters. And just why is -funroll-loops omitted from OPT_NORMAL? I've just tried making those three changes to a test build, and indeed this hurt performance a bit. In general, most distro packages of John I've seen so far override the CFLAGS in a way that often results in worse performance. This is not just an arbitrary piece of software where the distro knows better; for JtR, it's usually the other way around. Why not just disregard the policy and drop those overrides? OK, it sometimes makes sense to add things such as -march=..., but simply replacing all of CFLAGS with the distro's is often a bad idea. I guess I'll continue recommending custom builds over distro packages. > > http://cvsweb.openwall.com/john > > :) I have a nightly script that tracks various OSS projects and > syncs local copies of their SCM. Since I read that summary email > before this one, I was at least aware of the changes if not yet what > they did. Great. > Thanks! I'll re-base the patches off of those changes and submit them > in the next round. Would it be of any help if I release 18.104.22.168 now? (I guess so.) Thanks, 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.