[gentoo-amd64] Re: Re: Re: Giving up 64 platform

[Duncan]

Brandon Edens posted <20060425221729.GA8185@××××××××××××.edu>, excerpted
below,  on Tue, 25 Apr 2006 18:17:29 -0400:

> Thats interesting stuff Duncan. I've been looking for details regarding gcc's
> possible optimizations for AMD64 along with low-level details of what they do.
> Are you using gcc 3 or 4? Is there much work to be done, porting AMD64
> optimizations from 3 to 4's tree stuff? I'd like to read more or know where to
> find additional info.

I used 4.0.0 as my default compiler from the time it was released, altho
at first there were quite a number of packages I had to switch back to
3.4.x for.  The Gentoo devs that came up with Gentoo's slotting  idea and
then implemented it for gcc get major kudos for making that so easy! =8^) 

Then for a period I was using the 4.0.1-pre snapshots, as they almost
immediately fixed a couple regressions in 4.0.0.  When 4.0.1 release came,
I stuck with it, until 4.1.0 came out.  4.1.0 then became my default
compiler, while I have 4.0.3 and 3.4.6-r1 slotted in as well, when I need
to use them.  

While Stelling (Gentoo AMD64 Op Lead, seems quite active in all sorts of
things, from AMD64 to GCC to portage =8^) says 4.1.0 has a few regressions
that are now fixed, with the fixes to be released in 4.1.1 and of course
4.2.x, I've not seen them. 4.1.0 has been a /very/ smooth ride here. 
Smoother than any version of GCC since 3.2 or whatever it was that first
supported AMD64, before it even got the -march=k8 stuff. I believe there's
just one case I've had where I had to revert to 3.4.x, and the fact that
4.0.x didn't cut it either in that case almost certainly means the package
in question simply hadn't been patched to take 4.x's additional strictness
into account yet.  Of course, part of that is due to the much rougher
transition to 4.0, with its much stricter code requirements and early
regressions.  That's to be expected for what amounted to a huge rewrite,
for 4.0, however, and the change still wasn't as rough as the
incompatibilities introduced early in the 3.x cycle (at which point I was
just switching to Linux and using Mandrake, so I pretty much only read
about them).

IMO, 4.1 is the most significant improvement for AMD64 since we got
-march=k8 support in 3.3 (IIRC).  GCC's AMD64 support is finally
coming into its own! =8^)  There are a several reasons for this. 

One, the 3.x series simply wasn't designed with AMD64 as a major arch; the
support for AMD64 in 3.x was in many ways simply bolted on, and it showed.
 GCC3 simply wasn't designed to be able to take full advantage of the
optimizations possible for AMD64, as opposed to x86.  The rewrite for 4.0
was done with AMD64 in mind, and much better optimizations became possible.  

Two, the reorganization for 4.x gave GCC a much better organized and more
modular hierarchy in general -- one where it is possible to optimize to
greater efficiency because all that spaghetti code that was 3.x is gone,
and it's now far easier for dependant optimizations to be made up and down
the hierarchical chain without risking a serious miscompile regression due
to all the spaghetti code that 3.x had become. That's of course across all
archs, but it made optimizing for AMD64 that much easier, as it was no
longer treated as a special case of x86 in terms of branches off that
spaghetti code.  (IOW, there will be improvements for x86 as well, but
they won't be quite as dramatic, both because it was already quite
optimized, and because it was designed in as a major target, while AMD64
was bolted on, from the GCC3 perspectiive.)

Of course (and this is point three) the goal for 4.0 was simply to clean
out the spaghetti code and get the rewrite and new framework in place with
as few regressions (both in optimization and in downright miscompiles) as
possible. As such, it didn't advance the concept or optimization much
anyway, because that wasn't the goal, and any such changes intruduced for
4.0 just complicated the verification process, in terms of ensuring there
were no serious regressions, which /was/ the goal.  In that regard, 4.1 is
the 4.x series finally coming into its own.  The improvements made
possible by the overall rearchitecting in 4.0 finally begin to appear in
4.1.  The promise of 4.x is now delivered.

Together, those three points mean a HUGE step for GCC's AMD64 support, 3.x
to 4.1.x.  It's the first time it has been possible, and the differences
really /are/ noticeable.  

...

(Recall my earlier posting to the effect that xorg's composite rendering,
with xorg-7.0 (modular-X), as compiled by gcc-4.1, is actually practical
now -- it doesn't slow down the system to the point of unusability.  BTW,
while I'm not running xorg-7.1 due to stability issues this early in the
release cycle, I played with it a bit, and the improvements to EXA to the
point that it can replace XAA are dramatic!  Configuring 2D rendering to
use EXA on xorg-7.1, there is now virtually /zero/, that's  right, /zero/
additional CPU cost, to turning composite on!  I was literally ASTOUNDED! 
I couldn't have imagined it possible!  The significance in terms of
bringing transparency and etc to the X desktop is tremendous!  I had
thought that there'd always be an additional cost, and that only those
with the latest video cards (and slaveryware drivers) and just being
introduced CPUs would be able to run with the bells and whistles turned
on, and that we'd have to grow into it, but I was apparently and happily
very very wrong!  At least for those with Radeon 92xx series cards -- I've
a 9250 -- even running merged framebuffer with dual 1600x1200 monitors
resolution, the thing had such a low CPU cost that I literally couldn't
tell the difference, either in responsiveness or in the CPU activity
graphs, between composite with all the goodies on, and composite toggled
off altogether.  As I said, I couldn't have dreamed that was technically
possible!  Of course, that's compiling with gcc-4.1.0.  How it works when
compiled with 3.4.6, I really don't know, nor am I eager to personally
find out, tho I'm certainly open to reading the experiences of others.)

...

Back to GCC.  Looking forward, I see a number of additional significant
improvements marked out for gcc 4.2 and 4.3.  With the now clean code and
modular framework of 4.x, its promise of making additional optimizations
(and compiling speed improvements, lets not forget them) possible
continues to be delivered.  However, from 4.1, the improvements for AMD64
will probably simply be incremental once again, because 4.1 is where a
reasonably optimized gcc for amd64 was finally delivered.  It's the giant
step. Beyond that, improvements will continue, but should be much smaller
in comparison.

...

As for specific CFLAGS/CXXFLAGS, I posted mine with a fairly detailed
explanation of why I chose them, probably about a month to six weeks ago
(as a followon to that xorg 7.0 post mentioned above). I'd suggest looking
it up in the archives if you want the details, and the bit of further
discussion that followed.  I'll repeat here briefly.

CFLAGS="-march=k8 -Os -pipe -fomit-frame-pointer -frename-registers 
-funit-at-a-time -fweb -freorder-blocks -freorder-blocks-and-partition
-ftree-pre -fmerge-all-constants"

The -march and -pipe things are the usual.  -fomit-frame-pointer is
actually part of -Os (and -O2/3) on amd64.  I include it specifically
however, because some ebuilds use replaceflags or similar from flagomatic,
to change -Os into something else.  Since I haven't examined all of them
I use to be sure what the replacement would be, including
-fomit-frame-pointer specifically ensures it gets used, even if -O1 or
similar is used by the ebuild (unless of course -fomit-frame-pointer is
specifically deleted/replaced as well).  Also, for 32-bit compiling,
-fomit-frame-pointer kills certain debugging, so it's not default for any
-Ox.  Again, just include it so it gets used.  Similarly, -funit-at-a-time
is invoked by -O(s|2|3), from at least 4.0.  I'm not sure of its status
for 3.4, but it was only introduced with 3.3 (well, 3.2 Hammer editions,
IIRC), and had to be invoked specifically at that time.

-frename-registers and -fweb sort of go together.  Note that -fweb is NOT
recommended for gcc 4.0 where  it behaved somewhat strangely.  AFAIK it's
fine for 4.1 again.  The effect of both of these is to make more efficient
use of registers.  Note that -frename-registers is invoked by -O3 but not
-O2 (if memory serves).  That implies it might (haven't tested to
verify and haven't seen an explicit statement to that effect) increase
code size, undoing part of what -Os does, but the tradeoff should still be
worth it.

The -freorder-blocks flags go together as well.  With -and-partition,
reorder-blocks is redundant, but -and-partition is automatically disabled
in many cases where it can't work, so the weaker form is included to cover
that case.  The idea here is the hot/cold function separation mentioned
upthread.  Functions used frequently are grouped together such that they
have a better chance of staying in-cache.  Functions used infrequently are
likewise grouped.  From what I've read, this /does/ increase code size
some, but the tradeoff should be worth it because for most code, it'll
increase the cache hit ratio, which is why we are targeting size in the
first place.

**IMPORTANT**  C++ makes heavy use of exceptions where -and-partition
won't work, causing a warning to be emitted.  THIS WARNING BREAKS CERTAIN
CONFIGURE SCRIPTS. Thus, my CXXFLAGS are equivalent to CFLAGS minus
-freorder-blocks-and-partition.  I've had far less trouble with broken
emerges since I did that, and eliminating all those warnings is nice, too.

-ftree-pre is new to 4.x (so you'll want to eliminate it for 3.x
compiles, but the amd64 profiles have filtered out invalid flags
automatically for some time, now =8^). A weaker form of it is -ftree-fre
(partial/full redundancy elimination, full redundancy is faster to check
for but doesn't find as many cases, so it's weaker). The 4.1 manpage says
the -fre form is enabled by default at -O(1), the -pre form by -O2/3.  One
would guess it'd be logical to include it with -Os as well, but the
manpage doesn't say it is, so...  In any case, the same rule applies here
as above -- since I can't be sure an ebuild won't kill my -Ox setting, if
I really want the flag, it's best to include it specifically. If it really
doesn't work for a particular package, the ebuild should disable the flag
specifically anyway.

-fmerge-all-constants breaks the C specifications, so is never enabled by
default.  The weaker -fmerge-constants is C spec compliant, and is enabled
with any -O.  See the manpage for the details of the distinction and why
it should (in theory) be safe even if it breaks the spec.  In any case,
I've had no trouble with it, tho I was prepared to eliminate it if I did.
YMMV of course. This one should contribute significantly toward the goals
of -Os.

As with 4.1, I've had surprisingly few problems with this set of CFLAGS,
once I eliminated -freorder-blocks-and-partition from my CXX flags,
anyway.  They seem pretty solid, and I haven't verified whether it's the
CFLAGS or gcc-4.1 or both, but together, they make some rather
impressively fast code!  (Again, see the previous thread on xorg-7.0. 
Yes, the effect /was/ that impressive!  It felt like a good 50%
difference, which is truly astounding in an area where eking out a
hard-fought 1-2% improvement is far more common.  Again, xorg 7.1 with EXA
rendering in place of XAA looks set to repeat that, at least on my
hardware, as hard to believe as it may seem, this time due to xorg, not
the compiler, as I'm using 4.1 for both xorg-7.0 and 7.1.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-amd64@g.o mailing list