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
next prev parent 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).