mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Solar Designer <solar@openwall.com>
To: musl@lists.openwall.com
Subject: Re: crypt_blowfish integration, optimization
Date: Fri, 10 Aug 2012 21:18:03 +0400	[thread overview]
Message-ID: <20120810171803.GB29839@openwall.com> (raw)
In-Reply-To: <20120809223258.GW27715@brightrain.aerifal.cx>

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


  reply	other threads:[~2012-08-10 17:18 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-21 15:23 crypt* files in crypt directory Łukasz Sowa
2012-07-21 17:11 ` Solar Designer
2012-07-21 20:17   ` Rich Felker
2012-07-22 16:23   ` Łukasz Sowa
2012-07-25  7:57 ` Rich Felker
2012-08-08  2:24 ` Rich Felker
2012-08-08  4:42   ` Solar Designer
2012-08-08  5:28     ` Rich Felker
2012-08-08  6:27       ` Solar Designer
2012-08-08  7:03         ` Daniel Cegiełka
2012-08-08  7:24           ` Solar Designer
2012-08-08  7:42             ` Daniel Cegiełka
2012-08-08 21:48           ` Rich Felker
2012-08-08 23:08             ` Isaac Dunham
2012-08-08 23:24               ` John Spencer
2012-08-09  1:03                 ` Isaac Dunham
2012-08-09  3:16               ` Rich Felker
2012-08-09  3:36             ` Solar Designer
2012-08-09  7:13               ` orc
2012-08-09  7:28                 ` Rich Felker
2012-08-09  7:29               ` Solar Designer
2012-08-09 10:53                 ` Solar Designer
2012-08-09 11:58                   ` Szabolcs Nagy
2012-08-09 16:43                     ` Solar Designer
2012-08-09 17:30                       ` Szabolcs Nagy
2012-08-09 18:22                       ` Rich Felker
2012-08-09 23:21                     ` Rich Felker
2012-08-10 17:04                       ` Solar Designer
2012-08-10 18:06                         ` Rich Felker
2012-08-09 21:46                   ` crypt_blowfish integration, optimization Rich Felker
2012-08-09 22:21                     ` Solar Designer
2012-08-09 22:32                       ` Rich Felker
2012-08-10 17:18                         ` Solar Designer [this message]
2012-08-10 18:08                           ` Rich Felker
2012-08-10 22:52                             ` Solar Designer
2012-08-08  7:52     ` crypt* files in crypt directory Szabolcs Nagy
2012-08-08 13:06       ` Rich Felker
2012-08-08 14:30         ` orc
2012-08-08 14:53           ` Szabolcs Nagy
2012-08-08 15:05             ` orc
2012-08-08 18:10         ` Rich Felker
2012-08-09  1:51         ` Solar Designer
2012-08-09  3:25           ` Rich Felker
2012-08-09  4:04             ` Solar Designer
2012-08-09  5:48               ` Rich Felker
2012-08-09 15:52                 ` Solar Designer
2012-08-09 17:59                   ` Rich Felker
2012-08-09 21:17                   ` Rich Felker
2012-08-09 21:44                     ` Solar Designer
2012-08-09 22:08                       ` Rich Felker
2012-08-09 23:33           ` Rich Felker
2012-08-09  6:03   ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120810171803.GB29839@openwall.com \
    --to=solar@openwall.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).