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

[Brandon Edens]

On Tue, Apr 25, 2006 at 09:28:47PM -0700, Duncan wrote:

> 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.

As I figured after reading some of the optimization tree stuff. I can imagine
there were a bunch of AMD64 optimizations coded as a mish-mash of conditional
statements embedded in the existing x86 code. No good.

> 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.

I'm actually thinking more along the lines of the Cell processor and similar
technologies. My general notion is that the hardware designers want to shift
some of the burden of "keeping up with Moore's law" off to the compilers. In
that light it'd make sense that the GCC developers would want to shift
optimizations higher up in the analysis of source. 

> (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.)

I can definitely believe it. I saw that video of those two developers giving the
"wobbly window" demonstration. They were using some old Thinkpads as their
development platform. I think one of them had crummy on-board graphics, barely
supporting 3d, with 32MB of GPU RAM. Its funny how Microsoft is pounding the IT
sector with information about Vista Capable and the like. Drumming up PC sales
while xorg goes GL and proves you don't need a Vista capable sticker to get the
same sort of eye-candy effects. What kind of programmers do they have over at
Redmond anyway?!

> 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.

You've inspired me. I'll see about getting gcc 4.1 running on my laptop AND
finally learning how to correctly slot packages. To think I've gone this long
without properly reading the documentation. *DUCK*

Thanks for all the details Duncan. I appreciate it.

> 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.

Again thank you.

Brandon Edens