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 <gentoo-user+bounces-131271-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-user@lists.gentoo.org>; 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 <pandu@poluan.info>)
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 <gentoo-user@lists.gentoo.org>; Fri, 18 Nov 2011 08:35:02 -0800 (PST)
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
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: <CA+NOQxEreM57u56kQR4YS3LoiGbi6ZY+EAmMMEN=06gO=egipw@mail.gmail.com>
References: <4EC2B642.3010500@gmail.com>
<j9v1kh$6bi$1@dough.gmane.org>
<CAA2qdGXF9pfpsy7FvpPJtXvcDB0WJ+xD0SAURLLxsbm713FWpw@mail.gmail.com>
<201111160811.17331.stephane@22decembre.eu>
<CA+czFiDZ=2zuse5SxL9HuuG3z_v=2zKFqeV-2+=w6MyPOCpkZw@mail.gmail.com>
<CAA2qdGUoK65s-ppsUuSyTP0wFA9CaMrm30K=z+wQdAGCtoRqXg@mail.gmail.com>
<CA+NOQxEreM57u56kQR4YS3LoiGbi6ZY+EAmMMEN=06gO=egipw@mail.gmail.com>
Date: Fri, 18 Nov 2011 23:35:02 +0700
Message-ID: <CAA2qdGXXnDCE0_iBDBwrqJGJHei1_ZhsQN1wtREZFBmWbA_WTA@mail.gmail.com>
Subject: Re: [gentoo-user] Re: Upgrading gcc: both 4.4 and 4.5 needed?
From: Pandu Poluan <pandu@poluan.info>
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" <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 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 <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,
--0015173ff05037924504b204eb35
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p><br>
On Nov 18, 2011 10:41 PM, "Fredric Johansson" <<a href=3D"mail=
to:fredric.miscmail@gmail.com">fredric.miscmail@gmail.com</a>> wrote:<br=
>
><br>
> On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan <<a href=3D"mailto:pa=
ndu@poluan.info">pandu@poluan.info</a>> wrote:<br>
> ><br>
> > On Nov 16, 2011 2:26 PM, "Michael Mol" <<a href=3D"m=
ailto:mikemol@gmail.com">mikemol@gmail.com</a>> wrote:<br>
> >><br>
> >> On Wed, Nov 16, 2011 at 2:11 AM, St=C3=A9phane Guedon <<a =
href=3D"mailto:stephane@22decembre.eu">stephane@22decembre.eu</a>><br>
> >> wrote:<br>
> >> > On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrot=
e:<br>
> >> >> And if you're adventurous, add USE "graphit=
e", reemerge gcc, and<br>
> >> >> reemerge<br>
> >> >> world :)<br>
> >> ><br>
> >> > what does "graphite" add ?<br>
> >><br>
> >> Thanks for reminding me; I meant to look it up when I got hom=
e.<br>
> >><br>
> >> shortcircuit:1@serenity~<br>
> >> Wed Nov 16 02:16 AM<br>
> >> !501 #1 j0 ?0 $ euse -i graphite<br>
> >> global use flags (searching: graphite)<br>
> >> ************************************************************<=
br>
> >> no matching entries found<br>
> >><br>
> >> local use flags (searching: graphite)<br>
> >> ************************************************************<=
br>
> >><br>
> >> [snip]<br>
> >><br>
> >> [- =C2=A0 =C2=A0 =C2=A0] graphite<br>
> >> =C2=A0 =C2=A0sys-devel/gcc: Add support for the framework for=
loop optimizations<br>
> >> =C2=A0 =C2=A0based on a polyhedral intermediate representatio=
n<br>
> >><br>
> >> So, a new, experimental optimization model and framework insi=
de your<br>
> >> compiler. If it's specifically for optimizing on loops, I=
'll venture a<br>
> >> guess it's going to be mostly effective for graphics libr=
aries and<br>
> >> apps. I've got some slightly riskier educated guesses on =
how it works<br>
> >> and what some numeric side effects and consequences might be,=
but they<br>
> >> scare me, so I think I'll leave it to someone who actuall=
y knows more<br>
> >> about it...<br>
> >><br>
> ><br>
> > I've been using USE "graphite" since gcc-4.5.3-r1 a=
ppeared. Upstream says<br>
> > that graphite is stable, feature-complete, and production-ready s=
ince 4.5.3.<br>
> ><br>
> > To fully taste the effect of graphite, I even went the torturous =
route of<br>
> > emerging gcc + libtool + binutils (in that order) twice, followed=
by a<br>
> > wholesale-rebuild of everything (emerge --emptytree), then tarbal=
led the<br>
> > result to my own "stage3.1" tarball to spare me the *hu=
ge* amount of time<br>
> > required.<br>
> ><br>
> > I've deployed 3 systems with USE "graphite", and th=
ey *felt* snappier.<br>
> > emerge's *felt* slower, though. (no objective tests, I know).=
<br>
> ><br>
> > I use Gentoo as a gatewall, and there I did a wholesale-rebuild o=
ne more<br>
> > time, this time specifying CFLAGS "-march=3Dnative"... =
and I just couldn't be<br>
> > happier with the resulting performance :-)<br>
> ><br>
> > Rgds,<br>
> ><br>
><br>
> I might be wrong but don't you need to have the gcc's options =
for<br>
> graphite enabled to actually make use of the graphite framework? (You<=
br>
> might be using them but you haven't mentioned it.)<br>
></p>
<p>Yes. There are some CFLAGS incantations to add to fully utilize graphite=
, else the optimizations would be marginal at best.</p>
<p>That said, turning on the CFLAGS flags was a *very* involved process:</p=
>
<p>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.</p>
<p>2. I don't know if libtool and binutils need to be remerged, but I d=
id it just to be safe.</p>
<p>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).</p>
<p>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 :-) </p>
<p>5. Finally, universe-remerge (emerge --emptytree).</p>
<p>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 :-) </p>
<p>Of course, YMMV.</p>
<p>Rgds,<br>
</p>
--0015173ff05037924504b204eb35--