From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1506 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: crypt_blowfish integration, optimization Date: Fri, 10 Aug 2012 21:18:03 +0400 Message-ID: <20120810171803.GB29839@openwall.com> References: <20120808052844.GF27715@brightrain.aerifal.cx> <20120808062706.GA23135@openwall.com> <20120808214855.GL27715@brightrain.aerifal.cx> <20120809033613.GA24926@openwall.com> <20120809072940.GA26288@openwall.com> <20120809105348.GA27361@openwall.com> <20120809214654.GU27715@brightrain.aerifal.cx> <20120809222103.GA29365@openwall.com> <20120809223258.GW27715@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1344619086 6872 80.91.229.3 (10 Aug 2012 17:18:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Aug 2012 17:18:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1507-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 10 19:18:06 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Szsqb-00036z-SW for gllmg-musl@plane.gmane.org; Fri, 10 Aug 2012 19:18:06 +0200 Original-Received: (qmail 7192 invoked by uid 550); 10 Aug 2012 17:18:04 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7184 invoked from network); 10 Aug 2012 17:18:04 -0000 Content-Disposition: inline In-Reply-To: <20120809223258.GW27715@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:1506 Archived-At: On Thu, Aug 09, 2012 at 06:32:59PM -0400, Rich Felker wrote: > On Fri, Aug 10, 2012 at 02:21:03AM +0400, Solar Designer wrote: > > Hmm, for me "gcc -Q -O2 --help=optimizers" and ditto for -O3 both show > > "disabled" for -funroll-loops. Why was the loop unrolled for you? > > Not sure. I've found -Q --help=optimizers completely unreliable in the > past though. It only reports minimal differences between -Os, -O2, and > -O3, and trying to start with -O3 and reproduce -Os by just changing > the options that are different does not give effects even remotely > similar to -Os. Frankly, this matches my experience. OK, -Q --help=optimizers is unreliable. But is -O3 supposed to include -funroll-loops now? Does it? Or did you get loop unrolling done for some other reason? I think this needs to be understood by us. > > As discussed, the problem with avoiding such hand-unrolls is that the > > compiler doesn't know just which loops are most important to unroll. > > My experience has been that it tends to make good decisions overall, Yes, good decisions overall - like measured in terms of geometric mean or median for performance change across many functions (I wrote a script called relbench that reports such measurements for JtR builds) - but sometimes poor decisions for individual performance-critical functions. So hand-unrolling in those special cases helps. > and that if somebody is using -Os, they really want smallest size, not > performance. Maybe, however: So far, -Os was often providing good performance as well, on par with -O2. IIRC, in the relbench tests mentioned above, it was 92% of -O2 on gcc 4.6 on x86_64 for the geometric mean across about 150 separate benchmark results, but in some cases -Os code was actually faster than -O2. So someone using -Os may want nearly optimal code that is also slightly smaller. If for some function we get a more than ~8% hit with -Os vs. -O3 (or whatever does the unrolling), this means that the function could use some hand-optimization to fix that. Alexander