From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1RRRQF-0002d8-UE for garchives@archives.gentoo.org; Fri, 18 Nov 2011 16:36:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2EF0921C19A; Fri, 18 Nov 2011 16:36:06 +0000 (UTC) Received: from svr-us4.tirtonadi.com (svr-us4.tirtonadi.com [69.65.43.212]) by pigeon.gentoo.org (Postfix) with ESMTP id 7AAA721C06E for ; Fri, 18 Nov 2011 16:35:07 +0000 (UTC) Received: from mail-fx0-f53.google.com ([209.85.161.53]) by svr-us4.tirtonadi.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.69) (envelope-from ) id 1RRRPB-0024Qm-7c for gentoo-user@lists.gentoo.org; Fri, 18 Nov 2011 23:35:09 +0700 Received: by faan15 with SMTP id n15so5406268faa.40 for ; Fri, 18 Nov 2011 08:35:02 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 Received: by 10.205.121.1 with SMTP id ga1mr1584297bkc.60.1321634102743; Fri, 18 Nov 2011 08:35:02 -0800 (PST) Received: by 10.223.74.16 with HTTP; Fri, 18 Nov 2011 08:35:02 -0800 (PST) Received: by 10.223.74.16 with HTTP; Fri, 18 Nov 2011 08:35:02 -0800 (PST) In-Reply-To: References: <4EC2B642.3010500@gmail.com> <201111160811.17331.stephane@22decembre.eu> Date: Fri, 18 Nov 2011 23:35:02 +0700 Message-ID: Subject: Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed? From: Pandu Poluan To: gentoo-user@lists.gentoo.org Content-Type: multipart/alternative; boundary=0015173ff05037924504b204eb35 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - svr-us4.tirtonadi.com X-AntiAbuse: Original Domain - lists.gentoo.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - poluan.info X-Archives-Salt: 381c9c55-dd88-4ebf-9592-8e315dce8add X-Archives-Hash: ec425ef826cd0fafa780e4fecd59072e --0015173ff05037924504b204eb35 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Nov 18, 2011 10:41 PM, "Fredric Johansson" wrote: > > On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan wrote: > > > > On Nov 16, 2011 2:26 PM, "Michael Mol" wrote: > >> > >> On Wed, Nov 16, 2011 at 2:11 AM, St=C3=A9phane 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 th= e > > 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 mor= e > > time, this time specifying CFLAGS "-march=3Dnative"... 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
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=C3=A9phane Guedon <stephane@22decembre.eu>
> >> wrote:
> >> > On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrot= e:
> >> >> And if you're adventurous, add USE "graphit= e", reemerge gcc, and
> >> >> reemerge
> >> >> world :)
> >> >
> >> > what does "graphite" add ?
> >>
> >> Thanks for reminding me; I meant to look it up when I got hom= e.
> >>
> >> shortcircuit:1@serenity~
> >> Wed Nov 16 02:16 AM
> >> !501 #1 j0 ?0 $ euse -i graphite
> >> global use flags (searching: graphite)
> >> ************************************************************<= br> > >> no matching entries found
> >>
> >> local use flags (searching: graphite)
> >> ************************************************************<= br> > >>
> >> [snip]
> >>
> >> [- =C2=A0 =C2=A0 =C2=A0] graphite
> >> =C2=A0 =C2=A0sys-devel/gcc: Add support for the framework for= loop optimizations
> >> =C2=A0 =C2=A0based on a polyhedral intermediate representatio= n
> >>
> >> So, a new, experimental optimization model and framework insi= de your
> >> compiler. If it's specifically for optimizing on loops, I= 'll venture a
> >> guess it's going to be mostly effective for graphics libr= aries 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 actuall= y knows more
> >> about it...
> >>
> >
> > I've been using USE "graphite" since gcc-4.5.3-r1 a= ppeared. Upstream says
> > that graphite is stable, feature-complete, and production-ready s= ince 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 tarbal= led the
> > result to my own "stage3.1" tarball to spare me the *hu= ge* amount of time
> > required.
> >
> > I've deployed 3 systems with USE "graphite", and th= ey *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 o= ne more
> > time, this time specifying CFLAGS "-march=3Dnative"... = 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<= br> > 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 direct= ly turn on the graphite-related CFLAGS option. You must first enable USE &q= uot;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 d= id 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 ex= actly).

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 *hu= mongous* time to complete. But I am quite satisfied with the result. Everyt= hing felt snappier compared to older boxen that haven't been graphite-e= d :-)

Of course, YMMV.

Rgds,

--0015173ff05037924504b204eb35--