On Nov 18, 2011 10:41 PM, "Fredric Johansson" <fredric.miscmail@gmail.com> wrote:
>
> On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan <pandu@poluan.info> wrote:
> >
> > On Nov 16, 2011 2:26 PM, "Michael Mol" <mikemol@gmail.com> wrote:
> >>
> >> On Wed, Nov 16, 2011 at 2:11 AM, Stéphane Guedon <stephane@22decembre.eu>
> >> wrote:
> >> > On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote:
> >> >> And if you're adventurous, add USE "graphite", reemerge gcc, and
> >> >> reemerge
> >> >> world :)
> >> >
> >> > what does "graphite" add ?
> >>
> >> Thanks for reminding me; I meant to look it up when I got home.
> >>
> >> shortcircuit:1@serenity~
> >> Wed Nov 16 02:16 AM
> >> !501 #1 j0 ?0 $ euse -i graphite
> >> global use flags (searching: graphite)
> >> ************************************************************
> >> no matching entries found
> >>
> >> local use flags (searching: graphite)
> >> ************************************************************
> >>
> >> [snip]
> >>
> >> [-      ] graphite
> >>    sys-devel/gcc: Add support for the framework for loop optimizations
> >>    based on a polyhedral intermediate representation
> >>
> >> So, a new, experimental optimization model and framework inside your
> >> compiler. If it's specifically for optimizing on loops, I'll venture a
> >> guess it's going to be mostly effective for graphics libraries and
> >> apps. I've got some slightly riskier educated guesses on how it works
> >> and what some numeric side effects and consequences might be, but they
> >> scare me, so I think I'll leave it to someone who actually knows more
> >> about it...
> >>
> >
> > I've been using USE "graphite" since gcc-4.5.3-r1 appeared. Upstream says
> > that graphite is stable, feature-complete, and production-ready since 4.5.3.
> >
> > To fully taste the effect of graphite, I even went the torturous route of
> > emerging gcc + libtool + binutils (in that order) twice, followed by a
> > wholesale-rebuild of everything (emerge --emptytree), then tarballed the
> > result to my own "stage3.1" tarball to spare me the *huge* amount of time
> > required.
> >
> > I've deployed 3 systems with USE "graphite", and they *felt* snappier.
> > emerge's *felt* slower, though. (no objective tests, I know).
> >
> > I use Gentoo as a gatewall, and there I did a wholesale-rebuild one more
> > time, this time specifying CFLAGS "-march=native"... and I just couldn't be
> > happier with the resulting performance :-)
> >
> > Rgds,
> >
>
> I might be wrong but don't you need to have the gcc's options for
> graphite enabled to actually make use of the graphite framework? (You
> might be using them but you haven't mentioned it.)
>

Yes. There are some CFLAGS incantations to add to fully utilize graphite, else the optimizations would be marginal at best.

That said, turning on the CFLAGS flags was a *very* involved process:

1. By default, "graphite" is disabled. So you can't directly turn on the graphite-related CFLAGS option. You must first enable USE "graphite" and re-emerge gcc (or upgrade, if you're still using <gcc-4.5.3). This will pull in ppl and cloog-ppl.

2. I don't know if libtool and binutils need to be remerged, but I did it just to be safe.

3. Now that gcc has been compiled with graphite support, you can turn on the CFLAGS flags necessary to fully utilize graphite. WARNING: some flags recommended by upstream *might* make some programs run worse; be careful. (I won't have access to my servers so I can't tell you which ones exactly).

4. At this point, I want gcc itself to be optimized. So, I remerged gcc and libtool and binutils (in that order). Might be unnecessary, but I'm anal like that :-)

5. Finally, universe-remerge (emerge --emptytree).

As you can see, steps 4 & 5 are optional. And they indeed took a *humongous* time to complete. But I am quite satisfied with the result. Everything felt snappier compared to older boxen that haven't been graphite-ed :-)

Of course, YMMV.

Rgds,