1 |
On Nov 18, 2011 10:41 PM, "Fredric Johansson" <fredric.miscmail@×××××.com> |
2 |
wrote: |
3 |
> |
4 |
> On Wed, Nov 16, 2011 at 2:58 PM, Pandu Poluan <pandu@××××××.info> wrote: |
5 |
> > |
6 |
> > On Nov 16, 2011 2:26 PM, "Michael Mol" <mikemol@×××××.com> wrote: |
7 |
> >> |
8 |
> >> On Wed, Nov 16, 2011 at 2:11 AM, Stéphane Guedon < |
9 |
stephane@××××××××××.eu> |
10 |
> >> wrote: |
11 |
> >> > On Wednesday 16 November 2011 02:07:12 Pandu Poluan wrote: |
12 |
> >> >> And if you're adventurous, add USE "graphite", reemerge gcc, and |
13 |
> >> >> reemerge |
14 |
> >> >> world :) |
15 |
> >> > |
16 |
> >> > what does "graphite" add ? |
17 |
> >> |
18 |
> >> Thanks for reminding me; I meant to look it up when I got home. |
19 |
> >> |
20 |
> >> shortcircuit:1@serenity~ |
21 |
> >> Wed Nov 16 02:16 AM |
22 |
> >> !501 #1 j0 ?0 $ euse -i graphite |
23 |
> >> global use flags (searching: graphite) |
24 |
> >> ************************************************************ |
25 |
> >> no matching entries found |
26 |
> >> |
27 |
> >> local use flags (searching: graphite) |
28 |
> >> ************************************************************ |
29 |
> >> |
30 |
> >> [snip] |
31 |
> >> |
32 |
> >> [- ] graphite |
33 |
> >> sys-devel/gcc: Add support for the framework for loop optimizations |
34 |
> >> based on a polyhedral intermediate representation |
35 |
> >> |
36 |
> >> So, a new, experimental optimization model and framework inside your |
37 |
> >> compiler. If it's specifically for optimizing on loops, I'll venture a |
38 |
> >> guess it's going to be mostly effective for graphics libraries and |
39 |
> >> apps. I've got some slightly riskier educated guesses on how it works |
40 |
> >> and what some numeric side effects and consequences might be, but they |
41 |
> >> scare me, so I think I'll leave it to someone who actually knows more |
42 |
> >> about it... |
43 |
> >> |
44 |
> > |
45 |
> > I've been using USE "graphite" since gcc-4.5.3-r1 appeared. Upstream |
46 |
says |
47 |
> > that graphite is stable, feature-complete, and production-ready since |
48 |
4.5.3. |
49 |
> > |
50 |
> > To fully taste the effect of graphite, I even went the torturous route |
51 |
of |
52 |
> > emerging gcc + libtool + binutils (in that order) twice, followed by a |
53 |
> > wholesale-rebuild of everything (emerge --emptytree), then tarballed the |
54 |
> > result to my own "stage3.1" tarball to spare me the *huge* amount of |
55 |
time |
56 |
> > required. |
57 |
> > |
58 |
> > I've deployed 3 systems with USE "graphite", and they *felt* snappier. |
59 |
> > emerge's *felt* slower, though. (no objective tests, I know). |
60 |
> > |
61 |
> > I use Gentoo as a gatewall, and there I did a wholesale-rebuild one more |
62 |
> > time, this time specifying CFLAGS "-march=native"... and I just |
63 |
couldn't be |
64 |
> > happier with the resulting performance :-) |
65 |
> > |
66 |
> > Rgds, |
67 |
> > |
68 |
> |
69 |
> I might be wrong but don't you need to have the gcc's options for |
70 |
> graphite enabled to actually make use of the graphite framework? (You |
71 |
> might be using them but you haven't mentioned it.) |
72 |
> |
73 |
|
74 |
Yes. There are some CFLAGS incantations to add to fully utilize graphite, |
75 |
else the optimizations would be marginal at best. |
76 |
|
77 |
That said, turning on the CFLAGS flags was a *very* involved process: |
78 |
|
79 |
1. By default, "graphite" is disabled. So you can't directly turn on the |
80 |
graphite-related CFLAGS option. You must first enable USE "graphite" and |
81 |
re-emerge gcc (or upgrade, if you're still using <gcc-4.5.3). This will |
82 |
pull in ppl and cloog-ppl. |
83 |
|
84 |
2. I don't know if libtool and binutils need to be remerged, but I did it |
85 |
just to be safe. |
86 |
|
87 |
3. Now that gcc has been compiled with graphite support, you can turn on |
88 |
the CFLAGS flags necessary to fully utilize graphite. WARNING: some flags |
89 |
recommended by upstream *might* make some programs run worse; be careful. |
90 |
(I won't have access to my servers so I can't tell you which ones exactly). |
91 |
|
92 |
4. At this point, I want gcc itself to be optimized. So, I remerged gcc and |
93 |
libtool and binutils (in that order). Might be unnecessary, but I'm anal |
94 |
like that :-) |
95 |
|
96 |
5. Finally, universe-remerge (emerge --emptytree). |
97 |
|
98 |
As you can see, steps 4 & 5 are optional. And they indeed took a |
99 |
*humongous* time to complete. But I am quite satisfied with the result. |
100 |
Everything felt snappier compared to older boxen that haven't been |
101 |
graphite-ed :-) |
102 |
|
103 |
Of course, YMMV. |
104 |
|
105 |
Rgds, |